TET 
ÉVFOLYAM 
9. SZÁM 


518 


ISSN 158b5585 

I 09 
I HI A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
861518005 


97715 












1) 

n 

19 

Ed 

[7] 

har) 

sz 

TE 
6 7 
E pa 
(Alt Ez 
19. £ É 

[e] 
e - 
Óó KT 
JÉ] 7 
Ré [e árT) 
S 2.700 
-a- dési 
Hills-i c 
E Tár z 
tsz [játsz 
PF." 
(0 
"Be 
LN 








THERE IS NO SPOON! 





A ,tech.net magazin Brainstorm" a Dupla KV rovathoz 
hasonló, ám a személyes kérdésfelvetést és vitát is le- 
hetővé tevő rendezvény, melynek célja: 


e az elsőre talán ismeretlen technológiák 
élő bemutatása 

s a cikkekhez kapcsolódó kódok 
megírása/kipróbálása 

e a terjedelmi okokból kimaradt 
információk átadása 
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E magazinnal együtt a rendezvényre érvényes belépő- 
jegyet minden előfizetőnkhöz eljuttattuk. 
További információk a belépőjegyen olvashatók. 
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vői létszám (100 fő) miatt a regisztráció kötelező. Jelentkezzen, amíg nem késő!) 
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6 Öö SZ Öö NT 0) Közismerten bugnak ne- 
vezik a szoftverekben ta- 
lálható, jobbára átgondolatlanság miatt előforduló hibákat. Álta- 
lánosan elterjedt legenda szerint a bug (bogár) kifejezés erede- 
te abba a korba nyúlik vissza, amikor a számítógépek még sok e- 
zer tűzforró elektroncsőből épültek fel. Ezek a , számítógépek" 
szinte percenként hibásodtak meg teljesen maguktól is, egész 
egyszerűen a csövek átlagos élettartamának hossza, és a magas 
felhasználási darabszám miatt. Az idő előrehaladtával és a csö- 
vek minőségének javulásával (élettartamának növekedésével) 
egyre inkább csökkent a statisztikai módszerekkel előre megjó- 
solható leállások száma - maradtak viszont a látszólag értelmet- 
len, kiszámíthatatlan leállások, illetve számítási hibák. Ezek a 
(gre TAT LAT t e ele rázás jutatta uti tT4 e 1 8 
hatott a belsejébe, hogy forrasztópákájával rendet tegyen. Egy 
ilyen alkalommal talált egy bogarat, mely hősi halálával rövidre 
zárt egy áramkörrészt, s ezzel okozott számítási hibákat. 
Az eredendő bug tehát nem emberi mulasztásra vezethető visz- 
sza, manapság azonban szinte kizárólag ilyen értelemben hasz- 
náljuk: ha bugos a szoftver, akkor az emberi hiba következmé- 
LAZA AT PG ELLA LT elj eTO MENTA EZ P-n -de] 
nagyobb hiba kiváltására lehet felhasználni. 
Itt van mindjárt a Code Red. Semmi különös sincs a viselkedé- 
sében, hisz egy közismert programozási hiányosságot, a verem- 
re pakolt paraméterek ellenőrizetlen átvételét (buffer overrun) 
használta ki. Volt viszont ebben a kódban valami ördögi: köz- 
ismert hibák és gyengeségek kiaknázásával eddig ismeretlen 
méretű fertőzési hullámot okozott. Ismét meg kellett tanul- 
nunk, mit jelent, ha egy program memóriarezidens. 
De nemcsak a szoftverek bugosak, hanem a társadalmak is. 
Nyár végén, augusztusban történt, hogy elvetődtünk Ópuszta- 
szerre. Aki járt már ott, tudja: a bejárati pavilon előtti tű- 
ző napon, a sík betonon elviselhetetlen a forróság. Je- 
lentős sor állt bebocsátásra várva, s én csakhamar az 
ájulás szélére kerültem. Félig ép elmével, elhomályosu- 
ló tekintettel észrevettem, hogy be lehet osonni a pi- 
ramis alá, az árnyékba. Fogtam a két gyereket, és meg- 
mentettem őket is a biztos napszúrástól - csak a fele- 
ségem maradt a sorban, de ő néha önszántából is ki- 
megy a napra, így nem kellett féltenem. Bent látom 7 
ám, hogy személyit, útlevelet kérnek a látogatóktól. Va 
ela ET ee ee tát ee LELET AC HAL EZEL CET rez 
okozta, ami olyan komoly volt, hogy-nekem KN LELCCSKŐ 
tül be kellett vigyorognom az ablakon a nénihez, hogy 
mi bizony mi vagyunk, s a kilenc éves fiam rendelkezik, 
diákigazolvánnyal! S mindez miért? Mert aznap dl Lt 
magyarnak (határon innen és túl) ingyenes volt a be- 
lépés. Ottlétünk alatt a látogatók 10099-a bizonyult 
magyarnak. Kérdem én: nem lett volra egyszerűbb 
minden LEE Lee feltenni egy-egy kérdést magyarul? 
FL] válaszolni, az magyar, és már hus Ca ab is be.. 
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ségével megállapítódik, hogy tör- 
tént-e gyorshajtás, s annak díját is 
azonnal, automatikusan  ráverik a 
polgárra. Nincs kecmec és csúszó- 
pénz: ha valaki X távolságot kevesebb, mint Y idő alatt tett 
meg, akkor túllépte a sebességhatárt, akármit handaban- 
dázik is. Mi meg most szereljük le az autópályakapukat. 
-j Közintézményekben az ajtók mindig a menekülés 
irányában, nyomásra nyílnak; kilincs sincs, nehogy akadálya 
[eTO rát jer Tá si sének. Ez a szabály a toalettajtókra 
ELL LOG EG LUC OI CEL EN ÜT UE eezá bá a dB) 
A szervezettség kiterjed a turisztikai látványosságok körüli 
csődület kezelésére is: a repülőterekről ismert, terelőszalagok- 
kal határolt labirintust olyan ügyesen szabják a tömeg méreté- 
re, hogy mindenki azt hiszi, halad a sor. A World Trade Center 
aljában a biztonsági őrök bekapcsoltatják a turistával a video- 
kamerát, mert kíváncsiak, kamera-e egyáltalán. 
És mégis, ennyi szervezettség ellenére kiderült, hogy minden 
ember alkotta rendszer bugos. A mások által akár fel sem fe- 
dezett bugokra bizony éppúgy lehet , építeni" a valóságban, 
mint a szoftverek esetében. Cracker és terrorista ellen nincs or- 
vosság. Aki az életét teszi fel arra, hogy rendszereket döntsön 
romba, megkeresve a gyenge pontokat, az célt fog érni. Próbál- 
ná csak valaki , meghekkelni" mondjuk a természeti törvények 
valamelyikét. Ott nincs esély a gonoszkodásra. 
1 Me b ee LO Gate sake ere AVE ese 
5.2 "  pünkön. Változások előtt állunk, melyek re- 
ményeim szerint az elmaradott népek 
felemelése felé fognak irányulni, mert kü- 
lönben a nyomor elkeseredettsége újra és 
újratermeli az öngyilkosjelöltek hadsere- 
gét. Ne sajnáltassuk magunkat: Ma- 
gyarország népe messze a nyomorszint 
fölött él. Nálunk a legutolsó szakadt al- 
koholista koldusnak is naponta sokszor 
Tagra LL ere Teát eg -LK HA 
nem sorozzák be gerillahadseregbe, sen- 
kinek a családját, rokonságát nem fenye- 
geti sem éhezés, sem hajléktalanság, 
sem népirtás. Na jó, árvíz fenyegetheti. 
pEle enter egál 
Nekünk is Ces KG valahogyan 
ELVET É- B ú AE et sel számá- 
ra, de sajnos a Me bdatajú karattyoló TV 
net uzni SA ENE ilyes- 
miről nem beszélnek. USE Lee] 
ETTÉL LENÜL ELLE) ME 
HEESEER La Cr e iscltátát 
erjen ése Na ebből sem lesz TH KEZE Égi 
esztitsás ni .ETÉTsa Cr! LEE SZ 
past ba 2uhB uj je Kezdő 
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A Windows NT 
és a Windows 2000 


memóriakezelése 


avagy 


What is the Matrix? 

Sokszor elhangzó kérdés, hogy ha egy hálózatban X számú 
felhasználó van, Y darab megosztott könyvtárban dolgoz- 
nak Z darab fájllal, akkor mennyi RAM kell a Windows 
NT/SBS/2000 kiszolgálóba. Sajnos erre a kérdésre a Micro- 
soft modern operációs rendszerei esetén nincs egyértelmű 
válasz, mert a virtuális memóriakezelés virtualizálja a fogal- 
makat is. Mit tekinthetünk foglalt memóriának? Mi a sza- 
bad? Mikor kell lapozni? Ezekre sincs egyértelmű válasz: 
tiszta Matrix az egész. Amikor Neo megkérdezi, hogy a va- 
lóságot látja-e, Morpheus így válaszol: , What is real?" 

A valóság megismeréséhez kemény tanuláson kell átesni. Az 
alábbi cikk nem felületes olvasmány, akinek nem megy el- 
sőre, olvassa át mégegyszer! Ha kérdései vannak akkor pe- 
dig írjon a Windows 2000 listára. Vitassuk meg! 


Mit is jelent a virtuális memóriakezelés? 

How do you define real? 

Különösen fájó ez a gumivalóság, ha hardverbővítésnél kell oko- 
sat mondani, bár napjaink RAM árai mellett már könnyű benyög- 
ni a gigát - úgysem okoz gondot a kifizetése. Ennek ellenére úgy 
gondolom, érdemes megismerkedni a memóriafoglalás rejtel- 
meivel, mert teljesítménytuningoláskor nem árt a tisztánlátás! 
Kezdjük a virtuális memóriakezeléssel (VM): áldás, vagy átok? 
Sokak számára ez a fogalom az állandóan zörgő merevlemez- 
zel és a lassan vánszorgó rendszerrel azonos, legszívesebben 
kikapcsolnák - ha lehetne. Mindazok, akik a VM kikapcsolásá- 
val próbálkoznak, vasvillával hányják a diót a padlásra. A Win- 
dows XP-ben meg lehet szabadulni a lapozófájltól - de ez nem 
egyenértékű a VM kikapcsolásával. Aki komolyan gondolja, 
hogy neki nem kell VM, az telepítsen egy Windows 3.1-et, és 
a WIN.COM-ot mindig /r (real) kapcsolóval indítsa! 
Valójában a VM sokkal több előnnyel, mint nyűggel jár, nem 
csoda, hogy lassanként a konkurensek (Novell Netware, 
Apple Macintosh) is elérkeznek ide. Az sem igaz, hogy a VM 
egyet jelentene a lapozófájl zörgetésével, bár ha kevés a 
RAM, bizony előfordul ilyesmi. A VM alapvetően az Intel (és 
más gyártók) processzorainak hardverlehetősége arra, hogy 
az alkalmazások elől elrejthető legyen a párhuzamosan fu- 
tó több száz végrehajtási szál egymástól elkülönített me- 
móriaterületeinek borzalmasan bonyolult kezelése és védel- 
me. Ha kikapcsolható lenne a Windowsban a VM, megszűn- 
nének a védett memóriaterületek, és a rendszer stabilitása 
is! (Egyik Macintosh-használó ismerősöm csodálkozott rá a 
múltkor, hogy a Windows alatt van Task Manager, s hogy ha 
egy alkalmazás lefagy, attól még nem kell újraindítani a gé- 
pet. A Mac a mai napig nem tart itt!) 

A hardveres alaplehetőségre épít, és azt bonyolítja tovább a 
Windows, amikor kihasználja, hogy ha olyan memóriaterü- 
letre bökünk a címtérben, amely mögött nincs fizikai RAM, 
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akkor a gép nem lefagy, hanem ún. Page Fault megszakítást 
kezdeményez. A megszakításkezelő rutin pedig bepótolhatja 
a hiányzó memóriát, és utasíthatja a processzort, hogy tér- 
jen vissza a félbehagyott műveletre. A Windows esetében a 
memórialapok mérete egységesen 4 kilobájt, ami némi lapo- 
zási pazarlással jár, ha csak 3 k-t kellene belapozni, de bu- 
sásan megtérül abban, hogy a lapozófájl kezelése sokkal 
egyszerűbb: nem kell változó hosszúságú blokkoknak helyet 
keresni, nem kell töredék helyeket egybenöveszteni - egy- 
szóval nincs szükség szemétgyűjtésre (Garbage Collection). 
Először 1997-ben dühödtem be a VM működésének érthetet- 
lenségén. A rendszer megfigyelésével néhány olyan gondolat 
merült fel bennem, mely végül elvezetett a memóriakezelés 
megismeréséhez. Ezt követően került kezembe az Inside Win- 
dows NT egyik kiadása, melyben meglepve olvastam korábbi 
natív spekulációim igazolását. Az i-re a pontot pedig David 
Solomon mostani Tech.Ed előadása tette fel: tiszta a kép! 


Az első apró jelek 

Like a splinter in my mind that drives me mad 

Először gyakorló rendszergazdaként vettem észre, hogy va- 
lami nem stimmel a világgal. Volt egy hálózatom több száz 
olyan munkaállomással, melyeknek merevlemezére az Office 
egyszerűen nem fért fel. Mit tesz ilyenkor a rendszergazda? 
Elolvassa a dokumentációt, és felfedezi, a SETUP.EXE /A 
módszert, mellyel az Office hálózatos telepítésére is lehe- 
tőség nyílik. S fut a WINWORD.EXE a hálózati megosztásról, 
mint a kisangyal - de meddig? 

A kiszolgálók néha-néha lepihennek, ha nagyon fáradtak. 
(Nem, a Linux az nem. Meg a NetWare sem. S ha már itt tar- 
tunk: a Windows sem. Akkor biztos ZX Spektrum kiszolgálóim 
voltak. Ki emlékszik erre ma már?) Egy szó mint száz, az a 
VALAMILYEN kiszolgáló, amiről a Word futott, néha lepi- 
hent. Mit gondolnak, milyen közvetlen hatással volt ez a 
több száz felhasználóra? Döbbenetes módon 
SEMMILYEN 

hatással sem! Piri és Rozi zavartalanul csépelte tovább a 
Wordöt. Ez nem csoda - gondoltam - hisz a gépek leszedték 
a hálózati megosztásról az egész WINWORD.EXE-t a lapozó- 
fáljba (pagefile.sys). Egy pár perc múlva azonban szóltam 
Pirinek, hogy jobb lesz, ha mégis elmenti a művét, mert a 
kiszolgáló öt perce leállt. És abban a pillanatban, hogy a 
mentésre kattintott, a Word úgy elszállt, hogy öröm volt 
nézni. Piri is örült, s ennek egy cifra káromkodással adott 
hangot. Bár nem értettem a jelenséget, a zavartalanul dol- 
gozó Rozihoz új stratégiát agyaltam ki: neki azt mondtam, 
tegye vágólapra a művét. És csodák csodája, az akció sike- 
rült, a Word még elbillegett egy darabig, majd ugyanúgy ki- 
nyiffant, mint Pirinél, de a doksi megvárt minket a vágóla- 
pon. Mi a két eset között a különbség? Egyáltalán miért 
esett el a Word, ha egyszer bekerült a helyi Windows lapo- 
zófájljába? Hát, mert nem került bele. 
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WINDOwS 2000 


WINDOows 2000 


Sok-sok kísérletezés után rájöttem arra, amit kapásból tud- 
nom kellett volna: nem az egész WINWORD.EXE lapozódik 
ki, hanem csak az adatszegmensei! A kódszegmenseket fe- 
lesleges lapozófájlba tenni, hisz tökéletesen visszaállítható 
állapotban megtalálható valahol máshol: a megosztott 
könyvtárban a kiszolgálón! A Word addig képes futni, amíg 
képes pótolni a hiányzó EXE-falatkákat az eredeti fájlból. 

Tehát a lapozás, és a lapozófájl csörgése nem sok összefüg- 
gést mutat a programok kódszegmenseinek használatával. 
Ha kevés a memória, a Windows igen hatékonyan ,lapozza 
ki" a kódszegmensek tartalmát: egyszerűen eldobja! Az 
alábbi ábra ízelítőt ad a valóságról, s leolvasható róla a fu- 
tó WINWORD.EXE memóriadarabkáinak kilapozási útvonala. 


RAM terület 





PAGEFILE.SYS 


0 Egy alkalmazás kilapozása memóriahiány esetén. A 
szürke négyzetek a fizikai memóriában vannak — a többi 
terület nincs ott! 


A kódszegmensek elpárolognak, míg az adatszegmensek és 
a heap memóriablokkok (FONTOS.DOC) valóban a lapozófájl- 
ba kerülnek. 


Egy pár szó a Task Managerről 

All Im offering is the truth. Nothing more. 

Próbáljuk megállapítani az előbb emlegetett alkalmazás, a 
WINWORD.EXE összesített memóriafoglalását! Elsődleges me- 
móriaméricskélő eszközünk a Task Manager, a szokásos, alap- 
számlálókon kívül további memóriamennyiségek mérésére is 
képes. Az alábbi ábra bemutatja, milyen sokféle mennyiséget 
jeleníthetünk meg akár ezzel az egyszerű eszközzel is. 
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5 A Task Manager lehetőségei 
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Ha megjelenítjük mind a Memory Usage, mind pedig a Vir- 
tual Memory Size oszlopokat, érdekes felfedezést tehetünk: 
a két számoszlop között nem sok összefüggés mutatkozik, 
hol az egyik a nagyobb, hol a másik. Az alapnézetben is lát- 
ható Mem Usage az alkalmazásnak juttatott fincsi fizikai 
memória, míg a VM Size az alkalmazás pagefile.sys-be kila- 
pozott része. Ha pontosan tudni akarjuk az alkalmazás me- 
móriaéhségét, fejben gyorsan összeadjuk a kettőt, s meg- 
kapjuk azt a számot - melynek semmi köze semmihez... 

Ez azért van így, mert a korábbi, kilapozós ábra tanúsága 
szerint a végrehajtható kódrészek (a kódszegmensek) nem 
kerülnek ki a pagefile.sys-be, hanem , elpárolognak"! 

Falba ütköztünk: nem vagyunk képesek megmondani egy al- 
kalmazás összesített memóriaigényét - legalábbis a Task 
Manager nem segít ebben. 

Térjünk át a sokkal kifinomultabb Performance Monitorra 
(Windows 2000-ben System Monitor)! 


A Performance Monitor segítsége 

You mean I can dodge bullets? 

Első lépésként egyeztessük óráinkat, azaz állapítsuk meg, hogy 
az alábbi, Report nézetben használt PerfMon milyen számláló- 
kat mutat a kiválasztott Process objektumon, s ezek vajon 
megegyeznek-e a Task Manager valamelyik számlálójával. 
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x-€ú] Performance Logs and Alerts 





Page Faults/sec 

Page File Bytes 7143424.000 

Pool Nonpaged Bytes 11216.000 

Pool Paged Bytes 94200.000 

Private Bytes 7143424.000 
124260352.000 

Working Set 20488192.000 








[ [ [ 





5 Mit mond a Performance Monitor a WINWORD.EXE-ről? 
Rövid számológép-sanyargatás után rájövünk, hogy ami: 
sed PerfMonnál.. a Task Managerben... 


Page File Bytes ] WM Size 
Working Set MEM Usage 





Így csak öt eddig nem említett számláló maradt. Ezek közül 
három megjeleníthető a Task Managerben, de nem sok se- 
gítséget nyújtanak: 

"8 A Pool Paged Bytes az a kilapozható memóriamennyiség, 
melyet az alkalmazás részére a kernelben tart fogva az 
operációs rendszer (ablakkezelők (hWND) stb.) 

"8 A Pool Nonpaged Bytes az a NEM lapozható memória- 
mennyiség, melyet szintén az alkalmazás részére a ker- 
nel foglalt nekünk 

"8 A Page Faults/sec a másodpercenkénti ki-be lapozások 
mérőszáma 

Ismeretlenként tehát itt maradt a Private Bytes és a Virtu- 

al Bytes. Hátha ezek választ adnak a kérdésre: mennyit fo- 

gyaszt a WINWORD.EXE? 
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8 A Private Bytes azon memóriamennyiség, mely az alkalma- 
zás védett területén van, más processz nem férhet hoz- 
zá kívülről 

0 A Virtual Bytes pedig az alkalmazás által kért összes me- 
mória mennyisége 

Hopp! Úgy tűnik, helyben vagyunk! A Virtual Bytes megvá- 

laszolja a kérdésünket! Lássuk csak: 140951552 bájt, ami 

annyi mint 134,42 megabájt. Uramisten! Csak nem kap 
ennyit egy nyavalyás word? 


Konklúzió 

Welcome to the real world! 

Az élet szép, de a helyzet szomorú. A Virtual Bytes szépen 
megmutatja, hogy az adott alkalmazás mennyi memóriát 
KÉRT, de azt sajnos nem, hogy mennyit KAPOTT! (Ez utób- 
bi lenne a Committed Bytes, lásd később.) De legalább tet- 
ten érhető a virtuális memóriakezelés egyik igen jelentős 
előnye: az alkalmazások memóriaigénye akkor kerül kiszol- 
gálásra, ha az általuk , lefoglalt" területre valóban szüksé- 
gük lesz, oda írni, vagy onnan olvasni akarnak (Demand 
Paged Virtual Memory). Ilyenkor Page Fault (laphiány) 
megszakítás keletkezik, s az operációs rendszer gyorsan 
odadob egy adag memóriát, hadd higgye azt a Word, hogy 
megkapott mindent, amit kért! 


FONTOS! 

Valójában minden processz 0 (nulla) méretű Working 
Settel indul. Az alkalmazás mintegy ,befaultolja", 
behibázza" magát a memóriába, mert kezdetben nem 
kap egy fikarcnyi RAM-ot sem (kivéve az EXE legele- 
jét), és ahogy futni kezd, csapkod ide-oda, mindannyi- 
szor üres lapot talál, amit a VM kezelő bepótol neki! 


Ez a Windows 2000-nél még elég bután megy, mert - bár 
minden egyes alkalmazás mindig ugyanúgy indul - a 2000 
nem adja neki oda az indulólapokat, az EXE lassan , befaul- 
tolódik". Ez magyarázza, hogy például egy vacak kis CALC- 
.EXE közvetlenül indítás után miért mutat 334 Page Faul- 
tot, pedig senki sem bántotta! 

A Windows XP-n gyorsabban fognak indulni az alkalmazá- 
sok, mert meg fogja tanulni az induláskor szükséges lapo- 
kat, leteszi egy .PF (PreFetch) fájlba, és második indulás- 
nál már egy használható készletet tesz RAM-ba; nem nul- 
láról kell bemásznia szegény alkalmazásnak. 


A lapozásról 

How deep the rabbit hole is? 

A Process objektum számlálóival tehát nem jutottunk a dolog 
végére. Nem tudjuk, hogy egy adott pillanatban mennyit fo- 
gyaszt egy alkalmazás, sőt, azt sem tudjuk pontosan, miért 
nem tudjuk, amit nem tudunk. Térjünk át most a Memory ob- 
jektum számlálóira, hátha így közelebb jutunk a működés lé- 
nyegéhez. Itt van mindjárt az Available Bytes és a Cache By- 
tes számláló. Ha egy gépet terhelésnek teszünk ki, ez a két 
számláló gyönyörű szimmetrikus ábrákat rajzol a képernyőre. 
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5 Available Bytes és Cache Bytes a PerfMonban 


Mintha látszólag minden bájt, mely lefoglalódik, a cache 
területre kerülne, és fordítva. Mintha soha semmi nem ke- 
rülne át például a programok hatáskörébe. (Persze átkerül, 
ha indítgatunk és leállítgatunk programocskákat, de ha csak 
a meglévőkkel manipulálunk, ez ritkán látszik.) Mi valójá- 
ban az , Available Bytes"? És mi a , Cache Bytes"? 


Kövesd a fehér rabbit 

Az operációs rendszer futása közben állandóan zajlik a la- 
pozás. Ennek oka, hogy minden processznek korlátos a Wor- 
king Set mérete, s még rengeteg fizikai memória esetén is 
előbb-utóbb utoléri a végzet: bizonyos lapokról le kell mon- 
dania. Azonban ettől még nem fog zörögni a merevlemez. 
Ugyanis a Working Setből (LRU algoritmussal) kilapozott 
blokkok általában nem a merevlemezre lapozódnak, hanem 
előbb az úgynevezett Standby (rendelkezésre állási) memó- 
rialistára kerülnek. A Standby területen a memóriablokkok 
változtatás nélkül tárolódnak, hátha az LRU tévedett, és 
hamarosan ismét szükség lesz rájuk, így innen a Working 
Setből kilapozott blokkok mindenféle merevlemez-tekerés 
nélkül visszalapozhatók. A memóriából memóriába történő 
lapozást Soft Page Faultnak hívjuk, ellentétben a valóban 
lapozófájlművelettel járó Hard Page Faulttal. 


A Task Manager és a PerfMon-:Process objektum nem 
képes különbséget tenni a Hard és a Soft Page Fault kö- 
zött, így azok a számlálók gyakorlatilag használhatatla- 
nok a lapozófájlhasználat felbecsülésére! Egyedül a Perf- 
Mon-:Memória objektum ad valós képet a Pages/sec 
számlálóval, mert az csak a Hard Page Faultot méri 


A Standby listán kívül további memórialistái is vannak az 
operációs rendszernek, amint az az alábbi, David Solomon- 
tól lopott ábrán látható: 
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5 A Windows memórialistái 


A Working Setből a 4 kilobájtos lapok annak megfelelően 
szorulnak ki vagy a Standby Listre, vagy a Modified Page 
Listre, hogy tartalmuk módosult-e - azaz kód, vagy adat- 
szegmensről van-e szó. Ha egy alkalmazásból kilépünk, an- 
nak összes memórialapja a Free Page Listre kerül, felszaba- 
dul. Biztonsági okokból a Free listáról kizárólag olyan pro- 
cessz kaphat lapot, akinek amúgy joga lenne az adott lap 
olvasásához. Mivel azonban a kilapozott blokkban jelsza- 
vak, RSA kulcsok és egyéb érzékeny adatok lehetnek, a la- 
pok törlésen esnek át, mielőtt akármelyik processz kaphat- 
na belőlük. Így kerülnek át lenullázva a Zero Page Listre. Ha 
a szabad memória mennyiségére vagyunk kíváncsiak, nehéz 
helyzetben vagyunk, mert míg a Zero Page List nyilván sza- 
bad memória, addig a Free és a Standby így is, úgy is értel- 
mezhető: ha visszalapozzuk eredeti helyére, akkor inkább 
,cache", ha viszont újra kiadjuk, akkor szabad... 

A Task Manager és a PerfMon által mutatott Avaliable Bytes 
(a fenti gyönyörű diagramon az alsó vonal) valójában a Free, 
a Standby és a Zeroed listákon lévő memóriablokkok összes 
területe! 

Már csak egyetlen dolgot kell megválaszolnunk: mi a Cache 
Bytes? 


Cache Bytes 

There is no spoon 

A PerfMon szerint: , Cache Bytes is the sum of the System 
Cache Resident Bytes, System Driver Resident Bytes, System 
Code Resident Bytes, and Pool Paged Resident Bytes counters." 
Vagyis mindenféle System vicik-vacak által elfoglalt memó- 
riaterületek összessége! 

Ennek magyarázata a következő: nincs is olyan memóriatí- 
pus a Windowsban, hogy cache, mert a fenti listák gyakor- 
latilag elvégzik a gyorstárazást. Cache mechanizmus persze 
van: a Read Ahead, Lazy Write és a többi jól ismert algorit- 
mus itt is megvan, de nem egy különálló cahce manager- 
ben, hanem a VM memóriakezelés részeként. A trükk a kö- 
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vetkező: ha egy alkalmazás beolvas egy nagy fájlt, akkor a 
Read Ahead nem a hívó processz memóriaterébe dobálja az 
előrefutó olvasás eredményét, hanem az operációs rendszer 
saját Working Setjébe, hogy ha esetleg rosszul , gondolko- 
dott", és a Read Ahead eredménye mégsem kell az alkalma- 
zásnak, ne kelljen külön eltávolítania az alkalmazás memó- 
riateréből a kéretlen cuccot. E tény ismeretében érthető, 
hogy a Task Manager által mutatott Cache Bytes mást tar- 
talmaz NT4 és Windows 2000 esetén - hisz egyiknek sincs 
semmi köze a valósághoz. A , File Cache": 

"8 NTA esetén valójában a system working set mérete (paged 
pool 4. NtosKrnl.Exe, az eszközmeghajtók kód- és adat- 
szegmensei stb.) Semmi köze semmihez! 

"8 Windows 2000 esetén az NT4-es zagyvaság, plusz a 
Standby List mérete. 

A fura az, hogy a Standby List mérete beleszámítódik az 

Available Bytes-be is! Az Available és a Cache tehát sziámi 

ikrek, melyek a Standby Listnél fogva össze vannak nőve :) 






















































A Windows Task Manager hole 
Ele Options View Help 
Appkcations [processes [Performánce] 
f€PUUsage—  [7CPUUsage History ——————————— 
f MEM Usage —  f-Memory Usage History—————————— 
fr Totals Physical Memory (K) 
Handles. 7987 Total 126448 
Threads 393. [77 Avalable 7348 
Processes 42 System Cache 31032 
[7 Commit Charge (K) kernel Memory (K). 
Total Total 44636 
Paged 39412 
Nonpaged 5224 
fProcesses: 42 [EPUUsage: 1398 [Mem Usage: 186656K / 294300K 7 








5 A Task Manager buta arca. A dupla kurzor a sziámi 
számlálókat mutatja 


A Commit Charge pedig a lapozófájl méretéről ad közelítő- 
leges információt: A Memory-2Committed Bytes számláló 
ugyanis azt a mennyiséget mutatja, amennyit a Windows a 
kért memóriából valóban kiosztott, s melynek számára a la- 
pozófájlban fészket is rakott, hogy ha majd kilapozódik, ne 
kelljen helykeresgéléssel bajlódnia. Milyen kár, hogy a Com- 
mitted Bytes csak a Memory objektumon mérhető, s a pro- 
cesszeken nem! 


Főti Marcell 
marcellf onetacademia.net 
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Whistler 
(III. rész) 


Idén már két számunkban is éltünk a kiszivárogtatás populá- 
ris eszközével, de harmadszorra sem tudtam ellenállni a csá- 
bításnak, ezért íme egy újabb bennfenntes beszámoló a Win- 
dows következő változatának, a Whistlernek újdonságairól. 


Active Directory javítások 

Az Active Directoryban összesen több, mint 400 módosítás 
történik. Sémabővítés nem sok lesz, ugyanis kompatibilis 
marad a jelenlegi Windows 2000 sémával. Ami viszont a sé- 
mamódosítások visszavonhatóságát illeti: nos, ilyet az ere- 
deti Windows 2000 nem tud végrehajtani, így vegyes (2000 
és Whistler) tartományokban nem élvezhetjük az utóbbi 
összes újdonságát. Tisztán Whistleres környezet kell mind a 
négyszázvalahány újdonság használatba vételéhez. 

A szituáció ismerős, szinte déjá-vu: mint tudjuk, a Windows 
2000 Active Directory összes képességét nem használhatjuk 
vegyes (NT4 és 2000) tartományban. Csak akkor hullanak le 
a rabláncok a W2K AD-ról, ha az összes tartományvezérlő 
kétezres verziójú ÉS átállítjuk a tartomány Mixed-ről Native 
üzemmódra. A Whistler esetében is hasonló módon zajlik 
majd a frissítés. Miután az összes tartományvezérlő átállt 
Whistlerre, engedélyezni lehet a turbofícsöröket, át lehet 
állítani a tartomány Functionality Leveljét 0-ról 1-re. A nul- 
lás szint a Windows 2000, az egyes a Whistler, a kettes pe- 
dig a még fejlesztési stádiumban sem lévő 2005 utód lehet. 
(Látható, hogy most okosabb a Microsoft, mint két évvel 
ezelőtt, mert tetszőleges számú verzióváltást lehetővé tevő 
lehetőséget adtak maguknak a Functionality Level bevezeté- 
sével, szemben a Mixed-2Native megkülönböztetéssel, mely- 
nek lehetőségei máris kimerültek.) A Functionality Level 
átállítása a jelenlegi tervek szerint a sokak által utált, pa- 
rancssori NTDSUTIL segítségével történik majd. 

Szintén ide kapcsolódik az az új tartományvezérlők távoli te- 
lepítését megkönnyítő lehetőség, hogy a születő DC a kezde- 
ti replikációs feltöltést nemcsak hálózaton át lesz hajlandó 
befogadni, hanem (szalagos) mentésről is. Ezáltal lassú vo- 
nalak túlvégén is bátran belevághatunk majd a DCPROMO-ba. 


Active Directory Migration Tool 

Ha a tervek szerint halad a munka, az ingyenesen letölthető 
tartományátszervező eszköz, az ADMT is okosodik egy na- 
gyot. Eddig is lehetett vele objektumokat mozgatni tartomá- 
nyok között, de sajnos a jelszavak átvitelére nem volt képes. 
Az új verzióban állítólag megoldják ezt a nem kis problémát. 


64 bites Windows 

A Whistler lesz az első Microsoft operációs rendszer, mely 
átlép a 64 bites világba. Talán itt lenne az ideje a többi, 
szokásos korlát átlépésének is. A BIOS 7,8 gigabájtos álom- 
határától éppúgy megszabadulhatunk végre, mint a 2 tera- 
bájtos maximális partíciómérettől, mert magától a partíciós 
táblától válunk meg végre-valahára. MBR helyett jön a GPT, 
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azaz GUID Partition Tables. Már megint dobhatjuk ki jól be- 
vált lemezkezelő programjainkat... 


Rollback Driver 

Biztosan sokan belefutottak már hibás eszközmeghajtó 
okozta problémákba. Az új driver lecseréli a régit, és felül- 
firkantja a registryt. Már az NT korábbi verziói is lehetővé 
tették a regisztrációs adatbázis módosításainak visszavoná- 
sát az úgynevezett Last Known Good indítás segítségével, 
ám ez a lépéssorozat nem állítja vissza magát az eredeti 
eszközmeghajtó fájlt (".SYS). Ha tökéletesen szerencsétle- 
nek vagyunk, a frissítési szándékkal telepített változat ál- 
tal letörölt korábbi, működő SYS volt az utolsó fellelhető 
példány a földkerekségen. Már nem gyártják, s a weben 
sincs hozzá eszközmeghajtó. 

A Whistler azonban nemcsak Update Driver, hanem Rollback 
Driver nyomógombbal is dicsekedhet, mert új meghajtó telepí- 
tésekor nem letörli, hanem elraktározza az előző verzió(ka)t. 


DNS forwarding 

A DNS nélkülözhetetlen szolgáltatás az Active Directory 
alatt, így a vállalat összes tartományi gépe azt a DNS ki- 
szolgálót használja, amelyiken az AD regisztráció van, kü- 
lönben nem működne a tartomány. Ez azzal jár együtt, hogy 
minden DNS kérés - beleértve az Internetes névfeloldási 
műveleteket is - ugyanezen a DNS kiszolgálón köt ki, s az 
továbbítja a megfelelő helyre. Illetve nem a megfelelő, ha- 
nem (és ez nagy különbség!) a beállított helyre. Elágazást 
nem lehetett eddig megvalósítani, így néha igen trükkösen 
kellett felfűzni a vállalat DNS Servereit egy elágazásmentes 
Forwarder láncba. A Whistler lehetővé fogja tenni, hogy 
FODN alapján szétválogatva kerüljenek továbbításra a kéré- 
sek. A belső kérések például a junixra, az Internetesek pe- 
dig az Internetszolgáltatóhoz. 


NTFS Permission Calculator 

Megkaptuk amit kértünk: tíz év vajúdás után megszületett 
az effektív jogokat kiértékelő eszköz. Csak beírjuk neki, 
hogy melyik fájlon, és kinek a jogait szeretnénk megtudni, 
és már indul is a folyamat: allow -- deny 4 örökölt jogok 
ownership 4 csoporttagság -- rendszerszintű jogok (pl. back 
up files and directories) stb. beszámításával megkapjuk a ki- 
szemelt felhasználó jogait egy adott objektumon. (A Novell 
NetWare 3.11 nyomán...) 


Fóti Marcell 
(már) MCSE 2000 
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Emlékszem, pár évvel ezelőtt az útválasztás nemigen oko- 
zott fejtörést az IT szakemberek többségének: a hálózatok 
összekapcsolása (ha voltak egyáltalán hálózatok!) még 
nagyvállalatoknál is ritkaságszámba ment, s Internetkap- 
csolata sem volt senkinek. Nem túlzok: senkinek! De elmúl- 
tak már azok a boldog békeidők, amikor hálózat alatt egy 
másfél méteres koax kábelt, két T dugót és két lezáró el- 
lenállást értettünk, s annak is vége, hogy , majd a Novell 
két kártyával elintézi", hisz az IPX protokoll is kihalóban 
van. Nézzünk szembe a tényekkel: a hálózatok rohamos bur- 
jánzása következtében a rendszergazdák folyamatosan fog- 
lalkoznak a problémával, s heti gyakorisággal kerülnek dön- 
téshelyzetbe: kell-e új subnet? S ha igen, milyen IP tarto- 
mányt kapjon? Mi fogja összekötni az új alhálózatot a régi- 
vel? Egy router? Milyen gyártmány? Milyen routing proto- 
kollt kell ismernie? Mennyibe kerül? 

Minden döntési helyzetben célszerű legelőször megvizsgál- 
nunk a szerszámosládát, hátha már birtokunkban van az a 
szerszám, amire éppen szükség van. Az RRAS szerszámoslá- 
dája igen gazdag. Nem mindenki tudja talán, de egy közép- 
kategóriás hardver útválasztót meghazudtoló funkciógaz- 
dagságú és teljesítményű eszköz van a birtokunkban! Is- 
merkedjünk meg a használatával, hátha beválik. A ládafia 
átkutatása előtt azonban ismerkedjünk meg az IP útválasz- 
tás gyönyöreivel és gyötrelmeivel. 


Az alapprobléma 

Miért kell egyáltalán törődnünk az útválasztással? Miért nem 

oldják meg a gépek önállóan ezt a feladatot? Mert a két pont 

közötti csomagátvitelért felelős IP protokoll nincs felkészítve 

ilyesmire (!), lehetőségei nagyon is korlátozottak: egyszerűen 

nem is teszi lehetővé egynél több hálózat használatát! Az 

eredeti IP specifikáció ugyanis két, egymással szorosan össze- 

függő korlátozást is tartalmaz egynél több hálózat esetére: 

1. szabály: Minden gép csak a saját hálózatára küldhet cso- 
magot. 

2. szabály: Ha mégis távoli hálózatra kellene küldeni a cso- 
magot, akkor az első szabály lép életbe. 

Tisztára, mint a ,férjnek mindig igaza van" feliratok az 

ajándékbolt falán. Vagy mint egy börtön: minden alhálózat 

egy-egy külön börtön. 

3. szabály: A rabok kintről csak az őröktől kaphatnak cso- 
magot. 

4. szabály: Ha mástól jönne a csomag, akkor az első szabály- 
lépne életbe. 

Egymással természetesen szabadon, a fegyőr közvetítése 

nélkül is kommunikálhatnak: arra való a radiátorcső :-) 

Az őrök , segítsége", közreműködése nélkül nincs lehetőség 

külső kapcsolatra. Ugyanez a helyzet az IP-vel. Amint külső 

hálózatra forgalmazunk, rá kell vennünk a fegyőrt, hogy se- 

gítsen. Mindenképpen szükségünk van egy segédre, egy pos- 

tásra, egy útválasztóra. Egyszerű esetben alhálózatonként 
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egyetlenegy ,fegyőr" van - ennek címét írjuk be a Default 
Gateway, vagy magyarul alapértelmezett átjáró helyére. 


Internet 
IP: 86.86.86.23 


IP: 172.16.0.1 


IP: 172.16.0.22 
SM: 255.255.255.0 
DG: 86.86.86.23 


5 Mi a hiba a fenti ábrán? (Rossz a DG.) 


Gyakori hiba, s MCP vizsgákon számtalan ravasz formában 
visszatérő feladat a Default Gateway helyes beállítása. A fen- 
tiek alapján egyértelmű, hogy ha egy számítógépen a beírt 
Default Gateway nem a saját routerünk innenső IP címe, ha- 
nem mondjuk például a túlsó lábát, vagy ad abszurdum az 
Elender egyik gépét adjuk meg (mondván, hogy az közelebb 
van az Intemethez, hű de jó gyors lesz a kapcsolat), akkor a 
gép nem lesz képes külső kapcsolatot építeni. Idegen nem áll- 
hat szóba velünk a saját fegyőrünk közvetítése nélkül! Nincs 
csalási lehetőség: ha nem él, vagy nem ismert a kapu őrzője, 
nem jöhet létre a kommunikáció a külső és belső felek között. 
A fegyőrös hasonlat egyetlen ponton sántít: ha hibás címet 
adunk meg alapértelmezett átjáróként, akkor nem a fegyőr 
állítja meg a forgalmat - odáig el sem jutunk. Az IP stack 
helyes átjáró hiányában helyben eldobja a kifelé irányuló 
csomagokat. A szétválasztás egyébként a saját és a címzett 
IP címéből képzett úgynevezett Network ID-k összehasonlí- 
tásán alapul: ha a két NetID azonos, közös alhálón va- 
gyunk. Ha nem - nem. A művelet a saját Subnet Mask se- 
gítségével történik olymódon, hogy a Maskkal kétfelé vág- 
juk a címeket, és ha a , bal" fele (Network ID) azonos a rab 
börtönazonosítójával, akkor irány a radiátor. A következő 
ábra az előző alapján készült, ahol immár helyes a DG címe, 
és megpróbáljuk megpingelni a 23.23.23.23 című gépet. Az 
ábra alsó felében látható, ahogyan a gép eldönti, vajon 
azonos hálón van-e a végállomással. 
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Internet 


PING 23.23.23.23 ú) 


IP: 86.86.86.23 


Ca 


IP: 172.16.0.1 


IP: 172.16.0.22 
SM: 255.255.255.0 








DG: 172.16.0.1  4§— mostjó! 
nyissz! 

Network ID ; Host ID 
172. 16. 0 ; 22 
ö3; 24. 23 , 23 
295.255.255 ; o 
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9 Az útválasztás módszere: az IP címek szétvágása a 
Subnet Mask segítségével. 


Itt jegyzem meg, hogy manapság minden Subnet Mask bal- 
ról csupa egyes, jobbról csupa nulla, például: 


255.255.192.0-11111111.11111111.11000000.00000000 


Az eredeti szabvány megengedett ,fésűs" maszkot is, 
melyben vegyesen szerepelhettek egyesek és nullák. Ezt 
egy későbbi RFC felülbírálta, valószínűleg azért, mert nem 
embernek való a vegyes maszkkal történő fejben számolás. 


Minden Windows router? 

A legelső szabálypár miatt minden fegyencnek el kell tudnia 
dönteni, hogy kommunikációs partnere belsős, vagy külsős. 
Ezen döntések meghozatalára minden IP alapú eszköznek 
szüksége van, azaz mindegyik IP eszköz egy-egy egyszerű 
útválasztó is egyben. Erről könnyen meg is győződhetünk, 
ha parancssorban kiadjuk a ROUTE PRINT parancsot. Az 
alábbi ábrán például egy Windows 2000 Professional (!) út- 
vonaltábláját láthatjuk, ennek sorai egy-egy feldolgozandó 
irányt jelölnek. Későbbi példáim könnyebb értelmezhetősé- 
ge miatt célszerűnek tartom a táblázat részletesebb elemzé- 
sét - hamarosan route tábla műtétre is sor kerül! 
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5 A Windows 2000 Professional útvonaltáblája 


A táblázat első két oszlopában a célhálózatokat olvashat- 
juk, a szokásos formában: 


IP címtartomány eleje Subnet Mask 


199.188.177.0 255.255.255.0 


Ez a két szám egyértelműen meghatároz egy IP tarto- 
mányt. Könnyedén kiszámítható a vége, a Subnet Mask 
ugyanis megadja, hogy hány IP cím esik ebbe a tartomány- 
ba: ahol nulla áll a maszkban, az mind ide tartozik (az a 
szabadságfokunk), ergo az utolsó IP cím ebben a kupacban 
a 199.188.177.255. Újabb dokumentumokban egy másik 
jelölésmód is előfordul: 


199.188.177.0/24 


A törtjel utáni szám megadja, hogy a Subnet Maskban hány 
egyes (1) bit van, a 24 tehát megegyezik a 255.255.255.0-val. 
A fenti ábrán látható útvonaltáblában tehát a következő 
hálózatok szerepelnek: 








úg bij Hálózat 

0.0.0.0 0.0.0.0 Default Gateway 
127.0.0.0 255.0.0.0 SELF 

172.16.0.0 255.255.0.0 Saját alháló 
172.16.0.111 255.255.255.255 Eza gép 








172.16.255.255 255.255.255.255  Subnet Broadcast 

224.0.0.0 224.0.0.0 Multicast 

255.255.255.255 — 255.255.255.255 Globális IP 
Broadcast 


A következő két oszlop a küldési MÓDSZER meghatározásá- 
ra való. Alapvetően háromféle módszer létezik: 


Ha a 3. oszlop. továbbítás 


egy ,idegen" IP cím a Célzott. A csomag az ,idegen" 

saját hálónkról (router, fegyőr) címre kézbesí- 

(Itt: 172.16.0.1) tendő 

saját címünk Üzenetszórás. Az Ethernet majd 

(Itt: 172.16.0.111) lerendezi. 

127.0.0.1 Lokális. A csomagot nem KI, 
hanem BE kell küldeni az 


oprendszerbe. 





Az Interface oszlopban a fenti három továbbítási mód ki- 
járatait, hálókártyáit láthatjuk, végül a Metric oszlop 
egyelőre nem fontos, majd ha jönnek a Routing protokol- 
lok, visszatérünk rá. 
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DG:IP1 


WINDOwS 2000 RRAS (II. RÉSZ) - 





5 Mi hova? 


A kiemelt sor értelmezése ezek szerint: a 172.16.0.111 cím- 
re ,induló" (valójában érkező) csomagokat a 127.0.0.1 
(SELF) címre kell továbbítani, tehát be a gépbe. De az is 
kiolvasható, hogy ha a célgép IP címe mondjuk 
193.193.193.193, akkor ... hogyis? Meg kell keresnünk a 
193.193.193-as subnetet a legelső oszlopban, s ennek sorá- 
ból kiderül, hogy hova kézbesítendő. Nos, 193-as sort nem 
találunk, de ott a 0.0.0.0, mely minden ismeretlen címre vo- 
natkozik, ,mindent visz": a 193-as címek, mint teljesen is- 
meretlenek, célzottan a 172.16.0.1-es címre továbbítódnak, 
ami nem más, mint a DG. Ezzel a trükkel megspórolhatóvá 
vált, hogy a világ összes IP tartományát fel kelljen sorolni a 
listában: ami nincs bent, azt lenyeli a 0.0.0.0 sor. 

A saját hálózatra való csomagok célcíme egészen másképp fest: 
mintha önmagunknak küldenénk (127.0.0.1 cs 172.16.0.111)! 
A paraméter helyes értelmezése: ezen a címen/kártyán kell 
kieregetni, de nem kell vele , célozni", az Ethernet majd elinté- 
zi a célba juttatást (üzenetszórás, ARP stb.). 

Fontos még ismerni a 127.0.0.1 címet: ezek megint mi va- 
gyunk, ez a speciális IP cím minden gépen önmagára mu- 
tat. A sor értelmezése: ami nekünk jött, az nekünk jött. 
Nem kell továbbküldeni. Ha megpingeljük ezt a címet 


PING 127.0.0.1 


Network Monitorral megfigyelhető, hogy a csomag ki sem 
jut a kábelre (nem látszik belőle semmi). Most lássuk, mit 
kell tennünk az útvonaltáblával a következő esetekben! 


Két hálózat összekapcsolása 

Ha mindössze két hálózatot (mondjuk két irodát) szeret- 
nénk összekapcsolni útválasztóval, nem kell törődnünk sem 
az RRAS útvonaltáblájával, sem a telepítővarázslóval. A lé- 
nyeg, hogy az RRAS routing engedélyezve legyen. Ilyenkor 
elegendő, ha az RRAS gépbe beteszünk két kártyát, azokon 
beállítunk két helyes IP címet, a két oldal munkaállomásai- 
nak DG-jét pedig egyszerűen az RRAS-ra irányítjuk. Ez azért 
elegendő, mert bár a munkaállomások ,ismeretlen" cím 
miatt, a 0.0.0.0 címre küldik a csomagokat, a középen álló 
RRAS mindkét hálózatról tud, így minden beérkező csoma- 
got ügyesen átemel a másik lábára. 
































DG:IP2 — DG:IP2 
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Még egyszerűbb a hálózat gépeinek felkészítése, ha az RRAS- 
ra felteszünk egy DHCP Servert, és mindkét kártya IP címtar- 
tományára felveszünk egy scope-t (IP cím készletet), ahol a 
DG mindkét szkópban a megfelelő RRAS lábra mutat. Több- 
kártyás gépen ennél többre nincs is szükség, mert a DHCP 
Server meg tudja különböztetni egymástól a bejövő kérése- 
ket, és automágikusan a megfelelő tartományból ad címet. 


Három alhálózat összekapcsolása 

Három hálózat láncba fűzése esetén azzal kell számolnunk, 
hogy a lánc végén tanyázó routerek már nem fogják ismer- 
ni a kettővel odébb található alhálózatot, mert oda nincs 
közvetlen hálózati kapcsolatuk. Lássunk példát! 











3. hálózat 
192.168.1.0 


2. hálózat 
172.16.2.0 


1. hálózat 
10.10.10.0 





5 Három alhálózat esetén már lesznek a routerek szá- 
mára ismeretlen, , távoli" hálózatok is 


Itt R1 számára a 3. hálózat közvetlenül már nem érhető el, 
ismeretlen. Első ránézésre úgy tűnik, hogy elkerülhetetlen R1 
és R2 felokosítása, útvonaltáblájuk felkészítése a távoli célok 
eléréséhez, hisz ha az 1. hálózat egyik munkaállomása R1- 
hez továbbít egy csomagot, melynek végcélja a 3. hálózat, 
akkor R1 csak néz bután, nem tudja merre van a tovább. 
Egy kis furfanggal azonban elodázhatjuk az útvonaltábla hek- 
kelését. Mit is kell csinálni minden ismeretlen csomaggal? 
Hozzávágni a DG-hez! Mi tiltja meg, hogy R1-nek is beállít- 
sunk DG-t? A következő ábrán a görbe nyilak a csomagátdo- 
bás útvonalát mutatják, ha mindkét routeren felvesszük a MÁ- 
SIKAT DG-nek. Fűszerezzük meg az egészet egy kis DHCP-vel 
is, és igazán könnyen kezelhető hálózathoz jutunk! 







Scope 1 Scope 2 DG:R1 






3. hálózat 
192.168.1.0 


2. hálózat 
172.16.2.0 


1. hálózat 
10.10.10.0 








DHCP Relay Agent 


a Három hálózat, ,routolás és DHCP 


A fenti ábrán a DHCP Servernek már három szkópja (IP cím- 
készlete) van, de csak kettő alhálózat gépei képesek köz- 
vetlenül címet kérni tőle. A harmadik hálózaton ilyen ese- 
tekben el lehet helyezni egy DHCP Relay Agentet, mely on- 
nan a DHCP címkérési broadcastokat unicasttá alakítva át- 
dobja a routeren túlra, majd a választ ismét broadcasttá 
alakítva visszajuttatja a kérelmezőhöz. 
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Alapprobléma II. - gép a köztes hálózaton 

Három alhálózatból álló környezetben már előáll az a prob- 
léma, amit az augusztusi NetMon cikkben részletesen ele- 
meztem: a középső, második hálózaton mi legyen a munka- 
állomások DG beállításával? Ha R1, az is rossz, ha R2, az is 
rossz, hisz mindkét esetben menthetetlenül duplázott háló- 
zati forgalom kerekedik, amint az ,ellentétes" irányba sze- 
retnénk küldeni valamit. Egyszerre kettő DG nem lehet, 
mert - mint emlékszünk - hiába adunk meg egynél többet, 
hármat vagy négyet, sajnos már a másodikat sem használ- 
ja a masina mindaddig, amíg az első elérhető. Emlékszik 
még valaki, mi erre a megoldás? A köztes gép útvonaltáb- 
lájának kiegészítése, amit okos routerek esetén maga az út- 
választó elintéz, ICMP Redirect üzenetek kiküldésével. A II. 
alapprobléma sokszorosan visszaköszön, ha hálózatunk 
egyre több alhálózatból épül fel, és eljön az a bonyolultság, 
amikor az ICMP Redirect nem oldja meg a problémát. Nem 
marad más hátra, hozzányúlunk az útvonaltáblákhoz... 


Négy hálózat összekapcsolása 

Ahogy bonyolódik a hálózat, úgy válik egyre nehezebbé 
pusztán ravaszsággal megúszni az útválasztótábla matatá- 
sát. Ha már négy hálózat felfűzésére van szükség... 







3. hálózat 
192.168.1.0 










1. hálózat 
10.10.10.0 


2. hálózat 
172.16.2.0 
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. .. akkor már nem segít a DG-trükk, ugyanis a középen álló 
R2-nél a ,gép a köztes hálózaton" esete forog fenn, és két 
DG-t kellene beállítani neki, ami nem megy. Nézzük meg, 
vajon R1 és R3 esetén beválik-e még a DG-csel: 

0 R1 ismeri az 1. és a 2. hálózatot. 

"0 Ha minden további ismeretlen csomagot gondolkodás 
nélkül áthajít R2-nek, akkor jól továbbítja a 3. és 4. 
hálóra való csomagokat! 

Ennek tükörképe az R3, mely így szintén jól működik, ha 
a DG-je ,középre", R2-re mutat. 

Az R2 tanítása viszont elkerülhetetlen. Ismerkedjünk meg 
a Route parancs használatával! 
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ROUTE ADD Új bejegyzés készítése az útvonaltáblába 
ROUTE CHANGE Meglévő bejegyzés módosítása 
ROUTE DELETE Sor törlése a táblából 








Így taníthatjuk meg R2-nek, merre van az első hálózat: 


route add 10.10.10.0 mask 255.255.255.0 172.16.2.33 
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Ahol a 172.16.2.33 cím R1 , innenső" lába. Hasonlóképpen 
tanítható meg neki a negyedik hálózat holléte: 


route add 4.4.4.0 mask 255.255.255.0 192.168.1.111 


ahol 192.168.1.111 az R3 ,innenső" lába. Szabadon kísér- 
letezhetnek Kedves Olvasóink a route tábla rongálásával, 
mert egyfelől mindig rendelkezésre áll a ROUTE DELETE, 
másfelől minden bajtól megszabadít egy jóízű reboot. Így 
nyugodtan kipróbálható, mit szól a masina, ha kiadjuk a 
következő parancsot: 


ROUTE DELETE 0.0.0.0 


Megszűnik a távoli hálózatok elérhetősége, de a dolog nem 
halálos, a 


route add 0.0.0.0 mask 0.0.0.0 172.16.0.1 


visszateszi a DG címet (Ahol a 172.16.0.1 a Kedves Olvasó 
alhálózatán lévő router címe)! 


N darab hálózat összekapcsolása 

A következő megoldandó probléma N darab alhálózat össze- 
kapcsolása. Az eddigiekből könnyen belátható, hogy a vé- 
geken található routerek esetén van némi remény DG-trükk- 
re, de csak addig, amíg azok összesen két hálózat összekö- 
tését végzik. Ha elkezdünk pókhálót alkotni, azonnal elillan 
ennek esélye, s marad a tanítás. Sajnos a routerek és útvo- 
nalak számával exponenciálisan növekszik a szükséges 
ROUTE ADD parancsok száma, és akkor még nem beszéltünk 
a hálózat önkarbantartásáról. Körülbelül négy hálózatig ér- 
demes kézzel bíbelődni az útvonaltáblákkal, ennél összetet- 
tebb hálózatok esetén kézimunkázni őrültség. 

A megoldást valamilyen útválasztó protokoll használata je- 
lentheti, melyek közös tulajdonsága, hogy az egyes route- 
rek által természetesen ismert hálózatok adatait automati- 
kusan átvezetik a többi routerre is. Természetesen ismert 
hálózatnak nevezem azokat, melyek közvetlenül a masiná- 
ba csatlakoznak: nem kell megtanítani egy routert olyan 
hálózat elérésére, mely közvetlenül csatlakozik hozzá! 

Két útválasztó protokollról szólunk a következő hónapban: 
a RIP és az OSPF-ről, sőt, megemlékezünk a hamis IP cí- 
mek által okozott útválasztási agyrémekről is. 


Fóti Marcell 
marcellfonetacademia.net 
MCSE, MCT, MCDBA, MZ/X 
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a (IX. rész): Jegyzetek 
a tűzvonalból 


Egy probléma megkeresése és megoldása nem túl hálás 
feladat. Arról szól, hogy valami nem úgy működik, mint a 
nagykönyvben, mi megkeressük a hibát, azután meg min- 
den úgy pöfög, ahogy kell. Elpocsékolunk egy csomó időt 
arra, hogy úgy működjenek az eszközeink, ahogyan maguk- 
tól is kellene. Néha csak egy-két órát kell rááldozni a 
feladatra, néha egy hetet, de igazából sohasem tudjuk az 
elején, hogy mennyi lesz a feláldozandó, ,kárba vesző" idő. 
Azért lássuk be: nagyon sok , misztikus" eseménnyel talál- 
kozunk , kiszámítható" számítógépes világunkban, és ez fe- 
lettébb bosszantó. Főleg akkor lehet dühös az ember, ha 
úgy érzi, nincs a kezében eszköz, amellyel a probléma fel- 
göngyölíthető lenne. Logikai problémakizárással, próba- 
szerencse elven, vagy ,kezdjünk mindent tiszta lappal" 
módszerrel dolgozunk ilyenkor, és csak reméljük, hogy sike- 
rül. Már azt sem bánjuk, ha nem tudjuk meg a hiba pontos 
okát, csak legalább működjön már az a fránya rendszer. 
Az alábbi eset megtörtént, és - okulására mindenkinek - 
szeretném megosztani, hogy akik nap mint nap a ,tűzvo- 
nalban" tevékenykednek, azokat bátorítsam a problémák 
újfajta megközelítésére. 


A környezet és a probléma 

Pár héttel ezelőtt üzembehelyeztünk egy Windows 2000 szer- 
vert, rajta egy terminál szerviz szolgáltatást. Az eszközt 
hasznossága és népszerűsége miatt hamar túlterhelték a fel- 
használók - nosza, itt az alkalom egy hálózati terhelés- 
megosztás (Network Load Balancing Service) életre keltésével 





egy másik szervert is beállítani. Némi elméleti kérdés tisztá- 
zása (unicast és multicast üzemmód, MaskSourceMAC és switch 
elárasztás probléma stb.), olvasgatás és próbálkozás után 
felállt az NLBS cluster a következő konfigurációban: két Win- 
dows 2000 Advanced Server NLBS-sel telepítve és egy hubra 
kötve. A szerverek multicast üzemmódban működtek. (Csak 
dióhéjban: Az NLBS kétféle üzemmódban képes működni: uni- 
cast illetve multicast módban. Az unicast és multicast itt ,,le- 
vel 27 szinten értendő, és nem IP szinten. Unicast esetén a 
szerverek elrejtik a saját MAC címüket, és egyetlen, közös MAC 
címmel jelennek meg. Ennek a megoldásnak előnye a kompa- 
tibilitás, hiszen egy unicast csomag a mindenki által ismert 
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normál csomag. Hátrány viszont, hogy a szerverek az azonos 
MAC cím miatt nem tudnak egymással kommunikálni, ezért 
gyakran egy második hálózati csatolót is tesznek a szerverek- 
be, amellyel a node-ok közti forgalom lebonyolítható. További 
hátránya az unicast üzemmódnak, hogy a switcheket zavarja, 
ha két portján is ugyanaz a MAC cím jelenik meg. Ezt ugyan el 
lehet rejteni egy registry beállítással (MaskSourceMAC-1), ek- 
kor viszont a switch egyáltalán nem tudja megtanulni a MAC 
címet és minden switchportot eláraszt forgalommal. A multi- 
cast üzemmód esetén az eredeti MAC cím megmarad, és 
megállapodás születik" egy közös MAC címről is. Így elkerül- 
hető a két hálókártya telepítése és a switch elárasztása is, 
kommunikálhatnak egymással a szerverek, viszont a multicast 
forgalom kompatibilitási gondokhoz vezethet elsősorban a ro- 
utereknél.) Az 1. ábrán látható módon felállt a rendszer és 
ment is, ahogy az a nagykönyvben meg volt írva. 

Aztán két hét múlva elromlott az NLBS. A jelenség nagyjából 
úgy festett, hogy a kliens megpróbált csatlakozni, már majd- 
nem sikerült, feltűnt a halványkék bejelentkező képernyő, 
majd hirtelen megszakadt a kapcsolat, pontosabban a szer- 
verek megszakították. A szolgáltatás pedig már épp eléggé 
fontossá vált ahhoz, hogy meg kelljen oldani a feladatot. 


Problémamegoldás kizárásos módszerrel 

Ahogy ez lenni szokott, először a problémát szerettük volna 
elhatárolni. Mindezt persze , takarékosan". Ugyan alapsza- 
bály, hogy egyszerre csak egy dolgot változtass, de ez annyi- 
ra lelassíthatja a problémamegoldást, hogy a gyakorlatban 
ritkán van türelme a rendszergazdának alkalmazni. Mi is el- 
tértünk néha a szabálytól. Biztosan az NLBS-sel van problé- 
ma - gondoltuk, mert a szerverek terminál szolgáltatása elér- 
hető volt, ha a saját nevük, és nem a clusternév alapján akar- 
tuk elérni. A switch és a hub nem lehetett hibás, hiszen ak- 
kor forgalom sem lehetett volna. S valóban, unicast üzem- 
módra átkapcsolva, megjavulni látszott a helyzet. Csakhogy 
így elveszítettük a lehetőségét, hogy egyik node-ról a mási- 
kat el lehessen érni, ezt pedig nem akartuk. Mindenképp meg 
kellett oldani a multicast üzemmódú működést. 


Kezdjünk mindent tiszta lappal! 

A teljes újratelepítést a végső időkre tartogatva, először csak 
az NLBS-t vettük le, és telepítettük újra - az eredmény vál- 
tozatlan. Vagy nem tudja megjavítani a telepítő a jelenséget, 
vagy az NLBS-nek nincs köze az egészhez, ezért nincs is ha- 
tása az újratelepítésnek. De biztos az NLBS a hiba forrása. 
Nem volt más hátra, újra kellett telepíteni legalább az egyik 
szervert. Megtörtént, és az NLBS-t újra beizzítva láss cso- 
dát: az eredmény ugyanaz, a hiba továbbra is jelentkezett. 
Ebből az következik, hogy: 1. Felesleges volt az újratelepí- 
tés. 2. Nem a Load Balacingben van a hiba, mert kizárt do- 
log, hogy egy frissen és hibátlanul felhúzott rendszeren 
sem működik hibátlanul. 3. Korábban már megállapítottuk, 
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hogy az NLBS-sel van a hiba, hiszen az unicast/multicast 
átkapcsolás megszüntette a hibás működést. Láthatóan 
egymásnak ellentmondó következtetésekre jutottunk 
sholtbiztosan hibátlan" logikával. Valamit újítani kellett. 


Próba - szerencse 

Vajon tényleg hibátlan az új telepítés? S ha igen, akkor ho- 
gyan lehet erről meggyőződni? Hát például egy teljesen el- 
szeparált mini hálózatban, ahol csak egy egytagú NLBS szer- 
ver üzemel, és egy ügyfél szeretne rákapcsolódni az eszköz- 
re. Ezt hamar össze lehetett hozni, hiszen csak egy hubra 
kellett kötni a klienst és a frissen telepített szervert, a hu- 
bot pedig le kellett választani a hálózatról. És a 2. számú 
csoda: az előbb még nem működő NLBS egyszerre megjavult. 
Vagyis: 1. Az újratelepített NLBS-nek kutya baja. 2. Ha egy zsi- 
nórátdugással megoldható a rejtély, akkor egyáltalán nem a 
Windows 2000 táján kell keresni a megoldást. Hanem akkor 
hol? Nos - akármennyire is fura - a hálózatban , valahol". Vé- 
gül is van ebben logika: az untig használt unicast forgalommal 
működik minden, de az ,egzotikus" multicast gondot okoz. 
No ez meghaladta a tudásunkat - szakértőket hívtunk. Jöttek. 
Hoztak egy sniffer programot, amely remek statisztikákat 
adott a hálózat forgalmáról, például, hogy a switch minden 
portján rengeteg a broadcast és multicast üzenet. A forrás az 
NLBS cluster közös MAC címe. Hát ez meg mi? Egy switch ugye 
azért switch, hogy megtanulja a MAC címeket, hogy azután 
csak a megfelelő portok között jöjjön létre kapcsolat. Egyéb- 
ként a program nem ismerte fel a csomagok pontos típusát, vi- 
szont azt látta, hogy minden másodpercben jön egy. Kellene 
már valami, ami látja, hogy mi van azon a fene hálózaton!!! 


Network Monitor 

A szakértők sajnos nem értettek a Network Monitorhoz, il- 
letve az volt a véleményük, hogy nem kell még a csomago- 
kat mikroszkóp alatt vizsgálni, a napnál is világosabb, 
hogy az NLBS-sel van a hiba és a Windows 2000-ben, te- 
hát egy, a Windows 2000-hez és a Load Balancinghoz értő 
másik szakértőre van szükség. Én viszont a NetMonra sza- 
vaztam (mégsem hiába jártatom a szám? - F.M.), és az 
alábbi eredményt kaptam: 
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5 A nyomtató közbeszól 


A ,beszélgetés" normálisan kezdődik. A kliens egy DNS 
névfeloldás után felveszi a kapcsolatot az NLBS adta szer- 
verrel. Háromcsomagos ,kézfogás" (chip-chip-choka), az- 
tán belemerülnek a terminálkapcsolat részleteibe. A har- 
mincadik csomagot kiemeltem, mert az igen furcsa volt. A 
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(IX.RÉSZ): JEGYZETEK A TŰZVONALBÓL 
szekvenciaszám 0-0, az ack pedig a háromcsomagos ,kéz- 
fogás" után az első csomagra vonatkozik. De ennél is ér- 
dekesebb, hogy a MAC címe nem azonos a korábbi szerep- 
lőkéivel. Egy idegen. Egy UFO. És mit csinál? ,.A.R.." — 
vagyis: Reset Connection. Egészen pontosan végigbön- 
gészve a csomagot kiderült, hogy az állomás IP címe 
megegyezik a cluster IP címével: 10.0.0.152. És ettől kezd- 
ve az UFO folyamatosan válaszolgat a kliensnek: , Reset 
Connection", ,Reset Connection" stb. stb. 

Itt a bibi. - A MAC címet ellenőriztük. Volt ilyen állomás: az 
egy hete üzembe helyezett K... típusú szép új hálózati nyom- 
tatónk. Csakhogy annak van saját IP címe, 10.0.0.74. Hoppá! 
A történet most már kikerekedik: A switchünk képtelen 
megtanulni a multicast címeket, ezért kiküldi minden port- 
ra. (Ezért tapasztalt a szakértőnk rengeteg multicast címet.) 
Amikor az ügyfél és a cluster kommunikálni kezd, ezt is 
multicast csomagokkal végzik, amelyet szintén kiküld a 
switch minden portra. A K... nyomtató ezt a multicast fo- 
lyamot a magáénak érzi (sic!) , majd hazudik egy jó nagyot 
(sic!), és azt mondja, hogy az ő IP címe azonos a szerve- 
rével. Végül közli a klienssel, hogy neki nincs , terminal 
service" portja, ezért minden ilyen irányú kérésre , Kapcso- 
lat megszakad" a válasza. És tényleg, ez megfelel a jelen- 
ségnek. Már majdnem felépül a kapcsolat, amikor megsza- 
kad. Ellenpróba: K... nyomtatót eltávolítjuk - és minden 
működik. A nyomtatót visszadugva a hiba újra előáll. 

És a megoldás? Ideiglenesen kitöröltük a nyomtató alapértel- 
mezett átjáróját, így a távoli telephelyek felhasználói újra bir- 
tokba vehették a clustert. Azután egy nyomtatószervert tet- 
tünk az - amúgy hálózati - nyomtatónk elé, és már helyben 
is használhattuk a clustert. Végül kaptunk egy ígéretet a gyár- 
tótól, hogy a nyomtató új firmware-t kap, amely majd nem 
tartalmazza a hibát. Egyelőre az örök rejtélyek birodalmában 
tanyázik, hogy vajon miért nem tudja az amúgy vadonatúj, 
C... típusú, nagyon korszerű switch megjegyezni, hogy hon- 
nan és hová kellene a multicast forgalmat irányítania. 


Tanulságok 

Nem mindig ott a hiba, ahol az felbukkan. Az egész hibake- 
resést hátráltatta, hogy végig a Windows 2000-re fogtuk a 
problémát, pedig az ártatlan volt. A , hagyományos" mód- 
szerek nem voltak célravezetők. Sok logikai hibát is elkövet- 
tünk - ezeket a történetben is benne hagytam, mert így 
őszinte. A szakértők néha nem tudnak segíteni. Végül: saját 
kútfőből és ingyenes eszközökkel megoldottuk a problémát, 
csak rá kellett szánnunk magunkat egy kis hálózati-forgalom 
elemzésre. - Szóval tényleg: Netmon, netmon, netmon... 


Lepenye Tamás, MCSE 
lepenyet omal.hu 
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Remélhetőleg az Olvasó is rájött már, hogy nem az aktuális 
bel-, vagy akár világpolitikai színpad mögé fogunk bepil- 
lantani a következő néhány oldalon (ha jól csinálják, oda 
úgysem lehet...) . Természetesen az operációs rendszer által 
futtatott folyamatok (processzek) végrehajtási szálairól 
(thread-ek), azok időzítéséről, futtatásáról lesz szó, egé- 
szen pontosan arról, hogy mikor ki ,fut", ki birtokolja a 
processzor(oka)t - az is kiderül majd, hogy a címben fel- 
tett kérdésre a Windows-világban nincsen konkrét válasz. 

Cikkünk David Solomon [1] Barcelonában, a Tech.Ed 2001-en 
elhangzott előadása, valamint ugyanő és Mark Russinovich 
Inside Microsoft Windows 2000 (Third Edition) [2] című 
könyvének aktuális fejezete alapján készült. Ez a könyv 
egyébként ajánlott, sőt, kötelező olvasmány mindenkinek, aki 
szeretne komolyabban foglalkozni a Windows lelkivilágával. 


Nagyvonalakban 

A Windows NT/2000 (továbbiakban csak Windows) preemp- 
tív, multitaszk operációs rendszer, amelyben a végrehajtási 
szálak prioritása határozza meg azok végrehajtási sorrend- 
jét, időzítését. A preemptív szó jelentése körülbelül ,elő- 
jog", ami bizony azt jelenti, hogy - igencsak nem demok- 
ratikus, de mégis működő módon - ha jön valaki, akinek 
nagyobb prioritása van, mint az éppen futó végrehajtási 
szálnak, azt bizony előreengedi a sorban (sőt, szerszámait 
eldobálva félreáll) , bármit is csinált éppen. Hogy ne legyen 
teljes káosz és anarchia, az ,elnyomottakat" az operációs 
rendszer néha különféle mannákkal segíti: hol a szál végre- 
hajtási idejét (kvantum) növeli meg picit (ha egyszer mégis 
rákerült a sor és futhat) , hol a prioritásán emel valamennyit 
(hogy mégis rákerüljön a sor és futhasson) . Mielőtt azonban 
az időzítés rejtelmeibe belemennénk, tekintsük át a folya- 
matok és végrehajtási szálak kapcsolatait. 


Folyamatok és végrehajtási szálak 

A felhasználó számítógépén alkalmazásokat futtat: ilyen al- 
kalmazás a szövegszerkesztő, a böngésző, vagy mondjuk 
egy könyvelőprogram. Az alkalmazás általában (bár nem 
mindig) egy folyamat, processz (process). Amikor az alkal- 
mazás elindításáról, leállításáról beszélünk, tulajdonképpen 


mindig az alkalmazást , képező" processzt értjük alatta. 


8 Windows Task Manager 


BEKEZD 











5 Ha hinnénk a Task Manager-nek, azt hihetnénk, a gé- 
pen egyetlen alkalmazás fut... 


Ha a Task Manager Applications oldalára kattintunk, láthat- 
juk az éppen futó alkalmazásokat - azazhogy a kép ezt su- 
gallja, holott ez természetesen nem igaz. Egyrészt, itt nem 
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Ki tartja 
a kezében 
a szálakat? 


láthatók a rendszert önmagát képező folyamatok, a rend- 
szerszolgáltatások, de még azok az alkalmazások sem, ame- 
lyek a TaskBar-on bújnak meg az óra mellett: 
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5 ... miközben a TaskBar-on sorakoznak az ikonok 


Ezek szerint a személyes tűzfalam, a vírusírtóm, az SOL Ser- 
ver Service Manager, vagy az ICO-m nem fut, esetleg nem 
is alkalmazás? Dehogynem! Csak a Task Manager nem telje- 
sen mond igazat (ez egyébként általában jellemző rá): az 
Application oldalon azok az alkalmazások láthatók, amelyek 
az aktuális felhasználó munkaasztalán nem rejtett ablako- 
kat birtokolnak. Nyissuk ki az ICO-t! Aktíváljuk a vírusírtót! 
Rögtön megjelennek a Task Manager-ben is. 
Van más apró hazugság is ezen az oldalon: az alkalmazás 
neve mellett látható állapotjelentés (Status), ami az esetek 
többségében , Running" (azaz: fut), illetve ,Not Respon- 
ding" (azaz: nem válaszol) . A feliratok azonban a háttérben 
teljesen mást jelentenek: 
"8 Running: a folyamat válaszol a Windows üzenetekre (fel- 
használói beavatkozásra vár); viszont nem fut sehova, 
0 Not Responding: a folyamat nem reagál a Windows üze- 
netekre, így a felhasználói beavatkozásra sem; de ettől 
még lehet, hogy teljesen jól érzi magát, sőt, fut, csak el 
van foglalva. Ilyenkor általában valamilyen I/O művelet 
(lemezes vagy hálózati kommunikáció) befejezésére vár. 
Szerencsére a Task Manager részletesebb információkkal is 
szolgál a Processes oldalon. Itt már a számítógépen éppen 
futó összes processz (folyamat) látható, köztük megtalálha- 
tók az előző oldalon felsorolt alkalmazások, de a többi alkal- 
mazásunk éppúgy, mint a rendszerszolgáltatásokat, sőt az 
operációs rendszer alapszolgáltatásait képező folyamatok is. 


Processzek és szülők 
Vegyük kicsit közelebbről szemügyre, mit árul el a Task Ma- 
nager egy folyamatról: 
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5 A Task Managerben kiválaszthatjuk, milyen informá- 
ciót szeretnénk látni a processzekről 
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Az alapértelmezésben kiválasztott információk mellett más 
adatokat is megjeleníthetünk, ha a Task Manager View me- 
nüjében a Select Coloumns... parancsot választjuk. Az áb- 
rán is látható listából a számunkra most a PID (Process 
Identifier) , a Base Priority, valamint a Thread Count mező 
érdekes. Kapcsoljuk is be ezeket a mezőket, később még jól 
jöhetnek (az oszlopok sorrendjét egyébként a Task Manager- 
ben húzd-és-ejtsd módszerrel át is rendezhetjük) . 
Minden processz rendelkezik egy saját azonosítóval (ez a 
PID, Process Identifier). Bármilyen műveletet végzünk, a 
háttérben mindig ennek az azonosítónak a segítségével hi- 
vatkozunk az adott folyamatra. Ezen kívül minden folya- 
mat tudja magáról azt, hogy ki a szülője (ki hozta létre). 
Ez az információ a Task Manager-ben közvetlenül ugyan 
nem látszik, de a tudást használja: ha egy folyamat nevé- 
re jobb gombbal kattintunk, a megjelenő menüben választ- 
hatjuk az ,End Process Tree" parancsot is, ilyenkor a Task 
Manager a szülőazonosítók segítségével felkutatja a roko- 
ni szálakat, feltérképezi a családfát, és módszeresen végez 
a famíliával (legalábbis a kiszemelt áldozattal és annak le- 
származottjaival) . Tiszta maffia. 
Igen ám, csakhogy minden processz csak a saját szülőjére 
emlékszik, a távolabbi rokonokra már nem. 
Hozzunk létre egy próbakörnyezetet: 
0 Nyissunk egy közönséges parancssori ablakot. 
"0 A parancssorba gépeljük be: start cmd. A parancs hatá- 
sára egy második parancssori ablak jelenik meg. 
0 A második parancssori ablakba pedig írjuk ezt: notepad.exe. 
A létrehozott családfát jól jelképezi a Windows 2000 
Support Tools-ban (amely minden Windows 2000 CD 
/support/tools könyvtárából feltelepíthető) található tlist /t 
parancs kimenete: 


c:"]VVtlist /t 


explorer.exe (976) Program Manager 
CMD.EXE (1768) W:(WINZKPROlSystem32lcmd.exe 
CMD.EXE (816) W:NWINZKPROlsystem32(CMD.EXE 
notepad.exe (812) Untitled - Notepad 


A parancs eredményéből csak az aktuális részt vágtuk be: 
látható, hogy az ,ősapa" az explorer.exe. A szülő-gyermek 
viszonyokat a behúzások jelzik; ha valakinek nincs őse 
(ilyen az explorer.exe is), az a sor bal szélére kerül. Ha az 
1768-as PID-jű cmd.exe-t és leszármazottjait leállítjuk 
(Task Manager, Processes oldal, End Process Tree parancs), 
az magával rántja a másik parancssori ablakot és - termé- 
szetesen - a NotePad-et is. Ha viszont a köztes parancsso- 
ri ablakot bezárjuk (a hagyományos módon), a tlist /t ki- 
menete így módosul: 


c: Vtlist /t 


explorer.exe (976) Program Manager 
CMD.EXE (1768) W:YVWINZKPROlSystem32lcmd.exe 


notepad.exe (812) Untitled - Notepad 
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A 816-os PID-jű cmd.exe már nem fut; a notepad.exe pedig 
velanyátlanodott" (egészen a sor elejére csúszott), és ponto- 
san ez menti meg az életét! Ha most végeznénk a cmd.exe- 
vel és gyermekeivel, a NotePad még vígan működne tovább. 


Az ne zavarjon meg senkit, ha esetleg egy gyermek 
processz PID-je alacsonyabb, mint a szülőjéé: a PID-k 
újrafelhasználhatók, ha valaki elengedi, egy követke- 
ző létrehozott folyamat felveheti. 


A végrehajtási szálak 

Minden processz legalább egy végrehajtási szálat tartal- 
maz, ez a processz úgynevezett ,Initial Thread" (kezdeti 
végrehajtási szál). Az operációs rendszer szempontjából 
igazán a végrehajtási szálaknak van értelme, az időzítés is 
végrehajtási szálakat kezel - a processz nem más, mint egy 
vagy több végrehajtási szál közös adminisztratív környeze- 
te. A kezdő thread később újabb szálakat hozhat létre egy- 
egy részfeladat elvégzésére. Ha a Task Manager-ben meg- 
figyeljük, a ,Threads" oszlopban láthatjuk, hogy melyik 
processz hány végrehajtási szál képében , testesül meg". 


8 Windows Task Manager 








NAVAPSVC.EXE 644 00 3888K — 3476K 


5 A Task Manager , Threads" oszlopában a végrehajtási 
szálak száma látható 


Észrevehető, hogy míg a notepad.exe megelégszik egyet- 
len végrehajtási szállal, a navapsvc.exe (egy vírusírtó rend- 
szerszolgáltatása) már nyolc szálat futtat. De próbáljunk 
csak a jegyzettömbben megnyitni valamit! A végrehajtási 
szálak száma azonnal megnő (a dialógusablak kezeléséhez 
a rendszer további szálakat hozott létre). 

















5 Process Viewer 


A fenti ábrán egy másik nagyon hasznos eszköz látható. Ez a 
Process Viewer (pviewer.exe), ami ugyancsak a Windows 2000 
Support Tools része. A Process Viewer jóval részletesebb infor- 
mációkkal szolgál, mint a Task Manager, láthatjuk például, 
hogy az egyes folyamatok, végrehajtási szálak milyen priori- 
tással rendelkeznek, illetve azt, hogy az egyes végrehajtási 
szálak mennyi processzoridőt használtak fel felhasználói és 
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privilegizált (rendszer) futási módban. Ha akarjuk, a ,Kill Pro- 
cess" gomb segítségével leállíthatjuk a kiválasztott folyamatot, 
de vigyázzunk, ez az eszköz véres kezű, és véresen komolyan 
veszi a kérésünket még akkor is, ha a szóban forgó áldozat ép- 
pen akár egy rendszerszolgáltatás (a Task Manager például az 
ilyen processzeket jogosultság hiányában nem hagyja leállítani) . 


A végrehajtási szálak futásának időzítése 

Időzítés tekintetében a processznek, mint fogalomnak 
nincs jelentősége: a Windows a végrehajtási szálak futását 
kezeli. Bár a rendszerben látszólag egyszerre akár több száz 
végrehajtási szál is futhat, valójában egyidejűleg csak 
annyi fut, ahány processzor van a gépben (ha több pro- 
cesszorunk van, alapértelmezésben bármelyik processzoron 
bármelyik szál futhat, de a végrehajtási szálak kiválaszthat- 
ják a nekik , szimpatikus" processzor(oka)t - ez a Processor 
Affinity -. Ilyenkor a végrehajtási szál csak a kiválasztott 
processzoron fog futni, még akkor is, ha a másik éppen üres- 
járatban van.) Hogy mégis fenntartsuk az egyidejűség lát- 
szatát, minden végrehajtási szál csak egy bizonyos ideig 
futhat, azután át kell adnia a helyét a következőnek. Azt, 
hogy a sorban ki következhet, a végrehajtási szál pillanat- 
nyi prioritása dönti el. Mindenekelőtt tekintsük át egy-egy 
végrehajtási szál életciklusát: 














































Végrehajtási szát Végrehajtási szál 
kilép létrehozása 
Újrainíciatizálás Taitiatizeú  ] Várakozási sorba helyezés 
(iniciatizólt. 0) 
Terminated tady 
tásra kés 
(befejezett, 4) Wa (futásra kész. 1) j 
ak es (várakozik, 5) b 
Kívátasztás [ § 
Végrehajtás futásra ú 
ködsdülői Transition z 
(átmeneti, 6) $ 



























gr 
StandBy 


Running 
(készentétben, 3) 


(fut, 2) Másik szál előjoga vagy ídőszelet vége 


























Belapozás (context-switching) és futtatás 


5 A végrehajtási szálak életciklusa 


A végrehajtási szál létrehozásakor inicializált (Initialized) 
majd futásra kész (Ready) állapotba kerül. A legtöbb szál eb- 
ben az állapotban időzik a legtöbbet. Amikor a rendszer a 
végrehajtási szálat kiválasztja futásra, készenléti (StandBy) 
állapotba kerül; innen pedig - hacsak közben nem , érkezett" 
egy magasabb prioritású szál - futó (Running) állapotba jut. 
Ebben az állapotban csak egy ideig maradhat, ezt az időt a 
szál részére fenntartott időszelet érték, a Ouantum határozza 
meg. Ha az időszelet lejárt, a végrehajtási szál újra a futásra 
kész állapotba lép. Ha a végrehajtási szál végleg befejezte a 
munkáját, leáll: befejezett (Terminated) állapotba kerül. 
Ezután a végrehajtási szálat vagy megszüntetjük, vagy később 
újrainicializáljuk (reinkarnáció). A végrehajtási szálak azon- 
ban sokszor nem töltik ki a rendelkezésükre álló időszeletet: 
egyrészt, önszántukból várakozó (Waiting) státuszba léphet- 
nek, amíg egy I/O művelet, vagy kernelfunkció visszatérésére 
várnak. Másrészt, a Windows saját hatáskörben felfüggeszthe- 
ti egy végrehajtási szál futását, ha azt észleli, hogy egy fon- 
tosabb szál kész a futtatásra. A Windows a következő esetek- 
ben dönthet az éppen futó szál megszakításáról: 

B Új végrehajtási szál futásra kész — mert új szál jött létre, 

vagy tért vissza várakozó státuszból 
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"8 Az éppen futó végrehajtási szál elhagyja a futó státuszt 
- mert lejárt a számára kijelölt időszelet; mert várakozó 
állapotba lépett, vagy mert végleg befejezte a működését 

"8 Valamelyik végrehajtási szál prioritása megváltozik - ha 
önmaga, vagy akár az operációs rendszer módosítja a 
szál prioritását 

8 Ha a futó végrehajtási szál Processor Affinity értéke meg- 
változik 

A fenti esetek mindegyikében a Windows megvizsgálja a fu- 

tásra kész szálak prioritását, és ha azok közül van, amely 

magasabb, mint az éppen futó végrehajtási szálé, bizony 

helycsere következik. Az aktuális állapot elmentődik, és a 

kiválasztott szál állapota töltődik be a helyére - ezt a mű- 

veletet nevezzük kontextusváltásnak (context switching). A 

végrehajtási szálak aktuális állapotát egyébként a Perfor- 

mance Monitorban is figyelemmel követhetjük: 





























5 A felső (vastag vonallal rajzolt) érték a NotePad, a 
másik kettő a Performance Monitor egy-egy végrehajtási 
szálának állapotértékei 


Az egyes értékek jelentését az előző ábrából leolvashatjuk. 
Látható, hogy a NotePad (felhasználói inputra) várakozó és 
futásra kész állapot között mozog, de futó státuszba - látszó- 
lag - soha nem lép. Hogy miért? Azért, mert egyprocesszoros 
gépen az adatok begyűjtésének pillanatában bizony a Perfor- 
mance Monitor adatgyűjtő végrehajtási szála fut! 


A prioritás 

A processzorhoz jutás előjogát a végrehajtási szálak prioritá- 
sa határozza meg. A rendszer , belül" 32 különböző prioritási 
szintet különböztet meg. A 32 szint két fő részre van osztva; 
az alsó értékek (0..15) az úgynevezett dinamikus, a felső rész 
(16..31) pedig az úgynevezett valósidejű prioritási értékek. A 
0 prioritási érték nem osztható ki, az mindig a Zero Page 
Thread tulajdona. A prioritási értékek ilyen durva szétválasz- 
tására azért van szükség, nehogy magát az operációs rend- 
szert képező végrehajtási szálak is áldozatul essenek a priori- 
tásért vívott harcban. Az operációs rendszer (pontosabban a 
kernel) végrehajtási szálai tehát eleve sokkal magasabb prio- 
ritásértéken futnak, mint a felhasználói szálak. 

A felhasználói felületre kivezetett prioritásértékek nem 
számszerűek, hanem szöveges megjelenésűek, úgynevezett 
prioritásosztályok. Minimális, közép és maximális értékeik a 
következők: 
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min. alap max. 

















Idle, Low üresjárati, alacsony 2 4 6 
Below Normal — normális alatt 4 6 8 
Normal normális 6 8 10 
Above Normal — normális felett 8 10 12 
High magas 11 13 61 
Real-Time valósidejű 22 24 26 


Minden szálnak két prioritási jellemzője van: az úgyneve- 
zett alap (base) és a pillanatnyi (current). Valósidejű prio- 
ritás esetén ez a két érték mindig megegyezik, dinamikus 
prioritás esetén viszont nem feltétlenül: a Windows a pilla- 
natnyi prioritást az igényeknek megfelelően változtatja. A 
prioritások értékét többek között a Task Manager, a Process 
Viewer és a Performance Monitor segítségével tekinthetjük 
meg (a feladatkezelővel az alap prioritást módosíthatjuk is). 
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hozzáfért a processzorhoz, legalább hadd használja kicsit to- 
vább). Az időszelet hossza egyébként eleve más-más a Pro- 
fessional és a Server operációs rendszereken, de ez a beál- 
lítás módosítható. A Ouantum alapértelmezett értéke Pro- 
fessional esetén 6, Server esetén 12; minden egyes óra- 
megszakításkor (x86 processzorokál általában 10; multipro- 
cesszoros rendszereknél 15 ms-ként) az időszelet értéke 3- 
mal csökken. Így könnyen kiszámolható, hogy egy-egy 
végrehajtási szál mennyi ideig használhatja a processzort. 
(Akit érdekel, miért pont 3-mal, az olvassa el az említett 
könyv idevonatkozó fejezeteit. ) 

Az optimális teljesítmény érdekében a Windows a végre- 
hajtási szálak időszeletének értékét is megnövelheti (gu- 
antum boost), mégpedig akkor, amikor az adott végrehaj- 
tási szál ablaka az előtérben van. Az alapértelmezett idő- 
szelet értéke; a boost engedélyezése, sőt még a boost ér- 
téke is beállítható, mégpedig a 


HKLMiSystemlCurrentControlSetiControl) 
4 PriorityControllWWin32PrioritySeparation 


registry érték segítségével. Az érték alsó hat bitje számít, 
az alábbi kiosztásban: 























o A NotePad végrehajtási szála prioritásértékének vál- 
tozása: a vékonyabb vonal az alap (base) a vastagabb 
a pillanatnyi (current) prioritás 


A fenti ábrán látható, hogyan változott a NotePad végre- 
hajtási szálának prioritása, miközben várakozott 0, mi- 
közben dolgoztunk vele O, illetve amikor alacsony (Low, 
8) vagy amikor magas (High, 9) prioritást állítottunk be 
neki a Task Manager-ben. 


Priority Boost 

A dinamikus prioritás változásai az úgynevezett Priority 
Boost (prioritás-növelés) következménye. A végrehajtási 
szál dinamikus prioritásértékét a Windows a következő ese- 
tekben emelheti meg: 

0 I/O művelet befejezése után 

Kerneleseményekre való várakozás után 

Az előtérben futó alkalmazás várakozó állapotból való 
visszatérésekor 

A felhasználói felület végrehajtási szálainál felhasználói 
aktivitás esetén 

"B Amikor egy végrehajtási szál már régóta nem futott 

A megemelt prioritású végrehajtási szálak előjogot kapnak 
a processzor használatára. A ,boost" mindig a végrehajtá- 
si szál alapprioritásához adódik hozzá, és hatása idővel el 
is múlik (a prioritás visszaáll az eredeti értékre). 


A 


Pi 


A Ouantum 
A dinamikus működés másik biztosítéka a végrehajtási szá- 
lak futási időszeletének változtatása (ha egy szál végre 
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5] 4 3 2 1 [ 0 
Short / Long Variable / Fixed Boost érték 








"8 Short / Long: A Ouantum hossza. 1: hosszú; 2: rövid; 
a többi érték esetén az alapértelmezés érvényesül 
(Pro: rövid, Server: hosszú) 

"8 Variable / Fixed: Legyen-e Ouantum Boost ? 1: igen; 2: 
nem; a többi érték esetén az alapértelmezés érvénye- 
sül (Pro: igen, Server: nem) 

"8 Boost értéke: ha a Ouantum Boost engedélyezve van, 
itt adhatjuk meg a növelés szintjét (értéke 0 .. 2 kö- 
zött mozoghat). 






Variable 
Fixed 


5 A lehetséges Ouantum értékek táblázata 


A System tulajdonságlapról megnyitható Performance Op- 
tions dialógus jól ismert kérdése ("Optimalize performance 
for: Applications / Background Services") is pontosan ezt a 
registry értéket módosítja, mégpedig az alábbiakra (a táb- 
lázatban szürkével jelöltük) : 

"8 Optimize for Applications: Short; Variable; Boost 2 (18) 
"2 Optimize for Background Services: Long; Fixed (36) 


Fülöp Miklós 
mick Enetacademia.net 


esetet Ez AL NET ö 
[11 http:, //www.solsem.com 
[2] http; //mspress.microsoft.com/prod/books/4354.htm 
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A lusta rendszergazda súlyos tévedése 

Főszereplőnk egy lusta rendszergazda, akinek biztosítania kell, 

hogy egyetlen felhasználó a következő 2-3 napban valamikor 

Interneten keresztül fel tudjon tölteni egy nagyobb fájlt egy 

fájlszerverre. A rendszergazda tudja, hogy a kiszolgálón Win- 

dows 2000 van, amelyben található egy FTP szerver. Mi sem 

egyszerűbb, mint azt elindítani, engedélyezni rajta az Anony- 

mous elérést és a Write műveleteket, valamint az IUSR GepNev 

felhasználónak Full Control jogot adni a C: INETPUBWFTPROOT 

mappára. Eközben a következő feltételezésekkel él: 

"0 A szerver létezéséről még nem tud senki, hiszen tegnap 
telepítettem. 

"8 Csak egy felhasználónak árulom el, hogy elérheti FTP-n 
keresztül, akkor más miért is próbálná. 

"8 Három nap múlva kikapcsolom az FTP servert, addig nem 
lehet gond, hisz csak három nap. 

Ténykedései eredményeként már másnap a következő érde- 

kes mappát találja a szerveren: 


Gr Csiinetpubiítproot [-IDLd 


] File Edt View  Favorites Tools Help 
J Adóress [DJ cstnetpublítproot J c 


Name / IT szel mee 
CAT File Folder 
normal mappa File Folder 
(E) normal fajl.txt 1KB Text Document 




















SZAZ E S Z EZ 
5 Gyanús mappa 


Mikor a mappa tulajdonságait is megnézi, meglepőt tapasztal, 
amikor pedig törölni sem tudja, kezd pánikba esni. Egyáltalán 
milyen üzenet az, hogy Cannot read from source file or disk ? 


Opens with Change. 
Location: C-Nnetpublítproot 
Size Obytes 


Size on disk: 0 bytes 
Createdt 
Modífiedt 


Accessed 


Attibutes TT Readonly TT Hidden Advanced... 


Cancel poly 


5 Ez egy érdekes mappa, nem sokat tudunk róla 


Az FTP szerver eseménynaplója pedig annyi bejegyzést tar- 
talmaz, hogy képtelen végigrágni magát rajta. Mindössze 
egyetlen nap telt el! 
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mappák 


Nagyon sok egyéb biztonsági ajánláson kívül azt sem vette 
figyelembe, hogy attól még, hogy ő nem árulta el senkinek 
a kiszolgáló létezését, az igenis látszik az Internetről. Nem 
kell hozzá más, mint egy egyszerű portscanner program, a 
jobbak még azt is kipróbálják, hogy be tudnak-e lépni 
Anonymousként az FTP szerverre [3]. 

Adott tehát egy könyvtár, amit le kéne törölni, de nem sike- 
rült sem Explorerből, sem pedig parancssorból, akárhogy pró- 
bálkozik az idézőjelekkel vagy a joker karakterekkel. Természe- 
tesen ír a NetAcademia Windows 2000 levelezési listájára, 
ahonnan nagyon sok jó ötletet kap, azonban mindegyik látvá- 
nyosan csődöt mond. (Nem mindig vagyunk ilyen bénák — a 
szerk.) Tartalékként maradnak még olyan javaslatok, hogy 
mountolja fel Linux alól a meghajtót vagy valami DiskEdit sze- 
rűséggel szerkesztgesse a lemezt közvetlenül, de ez már egy 
kicsit túlzás lenne. Nem marad más hátra, mint körülnézni az 
Interneten, hogyan is lehet azt a COM1 könyvtárat letörölni? 


MS-DOS kompatibilitás 

Egy ehhez hasonló probléma megtalálható az összes Microsoft 
operációs rendszer termékben - ráadásul szándékosan 
(0216654 [1]). Ennek oka pedig a kompatibilitás, méghozzá 
nem is akármivel, hanem a történelemkönyvekből jól ismert 
MS-DOS-szal. Még a legújabb Windows verziók is megőrizték 
azt a tulajdonságukat, hogy a fájlműveletek parancssorból is 
elvégezhetők, például a COPY, DEL vagy REN utasítás éppúgy 
használható, mint tíz évvel ezelőtt. Azonban ezeknek az uta- 
sításoknak szükségszerűen voltak és vannak határai, mert az 
MS-DOS idején bizonyos nevek device-ként szolgáltak, ezért 
ezeket nem használhattuk kötetlenül: CON, PRN, AUX, 
CLOCK$, NUL, COM1-COM9, LPT1-LPT9. Windows 2000 alatt is 
remekül tudunk fájlt létrehozni az alábbi módon: 


c:YVocopy con ujfajl.txt 
Ez lesz a fajl tartalma. 


e 


Befejezes CTRLtZ-vel. 


1 file(s) copied. 
er 


Ha azonban a kívánt fájl neve például COM1.TXT, próbálkozásunk 
szánalmasan csődöt mond, miközben bezsebelünk egy "Access 
is denied" üzenetet. Átnevezés esetén próbálkozásunk jutalma 
egy "A duplicate file name exists, or the file cannot be 
found" hibaüzenet. Vicces, hogy egyik üzenetből sem látszik, 
hogy a problémát valójában a foglalt név használata okozza. 

Ha a foglalt nevekkel Windows 2000 alatt Windows Explorer- 
ből játszunk, a hibaüzenet már egy kicsit többet mond (The 
filename you specified is invalid or too long). Ha azonban 
Windows 95 alatt próbálunk egy COM1 nevű mappát létrehoz- 
ni, akár sikerrel is járhatunk. A probléma akkor jön elő, ami- 
kor ettől a jólfésült könyvtártól szeretnénk megválni, mert 
sem az egyszerű DEL vagy RD parancs, sem pedig a Windows 
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Explorer nem lesz hajlandó ezt letörölni, a Windows 95 
ugyanis a soros portot próbálja szorgalmasan kiirtani, ered- 
ménytelenül. Ekkor az alábbi szintaxis vezethet célra: 


DEL W. Ve: inappanevtcoml 


A Windows 95-höz készült javítócsomag kiküszöböli a prob- 
lémát. A Windows NT és 2000 annyira immunis ezzel a prob- 
lémával szemben, hogy el sem tudják képzelni, hogy ilyen 
könyvtár létezhet. Ezért ha mégis lenne ilyen mappánk és azt 
törölni próbáljuk, a válasz: "Cannot read from source file 
or disk". Emiatt a cikk elején említett mappától sem tudunk 
így megszabadulni, még a bonyolított szintaxissal sem. 


POSIX 

Ha a mappatörléssel kapcsolatban tovább kutakodunk az 
Interneten, előbb-utóbb belefutunk a 0120716-os Tudás- 
bázis cikkbe (/1]), ami ugyanezt a problémát tárgyalja 
Windows NT és 2000 környezet esetére. A Windows NT-nek 
és a 2000-nek ugyanis van egy POSIX (egyfajta juniksz — a 
szerk.) alrendszere, ami igenis támogatja ezeket a foglalt 
neveket. Ennek az alrendszernek a segítségével lehet olyan 
mappát vagy fájlt létrehozni NTFS partíción, aminek a ne- 
ve a korábban említett foglalt kulcsszavak közül származik. 
Ha viszont POSIX bigyó hozta létre, akkor POSIX bigyó tö- 
rölje is le, azaz a sima Windows 2000 ezt nem támogatja! 
Nincs más hátra, szerezni kell POSIX-os törlő programot. 
A Windows NT ősidők óta hordozza magában a POSIX kompa- 
tibilitást, az esetek többségében azonban nem találkozunk 
ezzel. Ha Windows 2000 Serveren egy Active Directory-ban 
tárolt felhasználó csoporttagságát szerkesztjük, találhatunk 
egy Set Primary Group opciót, aminek tipikus esetben az ég- 
világon semmi hatása nincs, egyedül a POSIX alrendszer és 
Macintosh kliensek számára hordoz információt. 


IUSR. PORTAL Properties [Ld 


Femote control ] Terminal Services Ptofte. ] 


General ]/ Address ) Account ] Profie ] Telephones ]  Organizabon 
MemberOf — ]  Diakn — ] Environment] Sessions 





Piimary group: Domain Users 


] 
KA JONES ÉN ESS E FOSSE szetter e ! 
e Finay o] jou have Macintosh csants or POSDC compkant 





ET éred [Ae] 


5 Csak POSIX alkalmazásoknak fontos 


A POSIX alrendszer akkor aktiválódik, ha olyan alkalmazást 
indítunk, ami azt kihasználja. Ekkor elindul a SYSTEM32 
mappában található POSIX.EXE, ami ténylegesen el fogja 
indítani a PSXSS.EXE-t, a POSIX Subsystemet. Ez később 
tovább fut, a Task Managerben megtalálható, sőt még az 
End Processre is fittyet hány. Hol lehet ilyen alkalmazáso- 
kat találni? Legkönnyebben a Windows 2000 Professional 
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BIZTONSÁG TÖRÖLHETETLEN MAPPÁK 
és Server Resource Kit CD-n az APPSNPOSIX mappában, itt 
ugyanis számos UNIX-szerű segédprogram figyel. 


Élni 


] Fie Edt View  Favorites Tools Help 
BELE 0 H:lappstposix FE 











5 POSIX segédprogramok a Resource Kit CD-n 


Az egyes eszközökről részletes leírást az ugyanebben a 
mappában leledző POSIX.DOC szolgáltat. Ebbe belekuk- 
kantva ráakadhatunk az RMDIR.EXE-re, ami egy parancsso- 
ri eszköz és segítségével mappákat lehetne eltávolítani 
(ReMove DIRectory). Ennek használata előtt érdemes tud- 
ni, hogy a POSIX parancsok érzékenyek a kis- és nagybe- 
tűk különbségére, valamint hogy a mappákra és fájlokra a 
már megszokottól eltérően kell hivatkozni. Például: 


rm —d "//C/FoMappa/AlMappa/COM1" 


Ez valószínűleg remekül működik, a bevezetőben említett 
mappa törlésére azonban teljesen alkalmatlannak bizonyult. 


FTP ! 

Miközben sikerült megfejteni a Windows 9x-ek és a POSIX 
alrendszer hiányosságait és nehézségeit, háttérbe szorult 
az a tény, hogy a kérdéses mappát a rosszarcú júzer FTP-n 
keresztül hozta létre, márpedig ez nem közömbös! 

Ha egy FTP sessionben az MKDIR parancs segítségével lét- 
rehozunk egy mappát az látszólag teljesen ugyanúgy visel- 
kedik, mintha azt Explorerben vagy parancssorban az MD 
parancs segítségével tennénk. A kettő között igenis van 
különbség, még ha ez elég apró, akkor is. Példaként hoz- 
zunk létre mindkét módon egy új mappát a következő szin- 
taxissal. FTP-n keresztül simán megy: 


ftp: mkdir ./ujmappa/ / 
257 "./ujmappa" directory created. 


De parancssorból nem: 


c:Vomd" 


The syntax of the command is incorrect. 


.NMujmappaN " 


Pontosan ez az apró szintaxis-különbség, és ennek tovább 
bővített változatai adnak lehetőséget rosszalkodásra [2]. 
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BIZTONSÁG TÖRÖLHETETLEN MAPPÁK 
Törölhetetlen könyvtárak 

Az alapötlet az, hogy létrehozunk egy ,, " (azaz szóköz) 
könyvárat, ami nem látszik. Ehhez jelentkezzünk be a saját 
gépünkön levő IIS FTP szerverre, ahol már korábban enge- 
délyeztük a Write műveleteket is (IIS MMC snap-in, Default 
FTP Site Properties, Home Directory fül, Write beklikk) és 
NTFS szinten is van jogunk matatni a mappában. Ezután 
próbáljuk ki a következő parancsot: 


ftp? mkdir "./ ujmappa / /" 
257 "./ ujmappa / /" directory created. 


Az eredmény ugyanaz, mint amit a bevezetőben láthatunk, csak 
a mappa neve más. Akár be is léphetünk a mappába, de csak az 
alábbi szintaxissal (ez megy FTP nélkül, parancssori ablakból is): 


ftp, cd "./ ujmappa / /" 


250 CWD command successful. 


Ha törölni próbáljuk, akkor "Cannot read from source file or 
disk" illetve "The system cannot find the path specified" 
üzenettel lehetünk gazdagabbak. Próbáljuk inkább átnevezni, 
az átnevezés után már tudjuk törölni: 


ftp: ren "./ ujmappa / /" ujnev 
350 File exists, ready for destination name 
250 RNTO command successful. 

ftp: rmdir ujnev 


250 RMD command successful. 


Ugyanezzel a módszerrel készítette a felhasználó a beveze- 
tőben szereplő COM1 mappát is és ugyanígy lehet megválni 
tőle. Természetesen semmi akadálya, hogy a szóközök szá- 
mát variálva még jobban kiszúrjon bárki is a rendszergazdá- 
val, ugyanis a mappa törléséhez feltétlenül szükséges a 
pontos szintaxis, amit a ,hacker" használt. Ezt az FTP szer- 
ver naplófájljaiból tudhatjuk meg, melyek alapértelmezés 
szerint a SYSTEM32LogFilesMSFTPSVC1 mappában találha- 
tóak. Hogy az FTP szerver naplójába milyen mezők értékei 
kerüljenek, azt az Internet Information Services snap-inben 
a Default FTP Site Properties ablakában az első fülön a Pro- 
perties gombra kattintva tudjuk beállítani. 


Törölhetetlen fájlok 
Hasonlóan van lehetőség törölhetetlen fájl készítésére is, 
mégpedig átnevezéssel: 


ftp? rename matrix.mpg "ujnev ./ /" 
350 File exists, ready for destination name 


250 RNTO command successful. 


Ezt a fájlt letörölni nem lehet, csak ugyanilyen átnevezéses 

módon felülírni egy üres fájllal. Ott lesz, de legalább nem 

foglal helyet. (Megjegyzés: nekem még úgy sem sikerült le- 

törölni az így , írásvédetté" tett fájlt!) 

Az így elérhetetlenné és törölhetetlenné tett fájlok és map- 

pák elérésére nem minden FTP kliens alkalmas, a Windows 

2000-ben található FTP klienssel nekem nem sikerült hasz- 

nálnom a mappákat. Ez természetesen nem jelenti azt, 

hogy nem léteznek akár Windows, akár más operációs rend- 

szer alá a célnak megfelelő alkalmazások. Mivel a tapaszta- 

latok szerint az utólagos törlés nagyon nehézkes, célszerű 

megelőzni a bajt a megfelelő korlátozások beállításával. 

Csak néhány ötlet a sok közül: 

"8 Szükségem van-e egyáltalán FTP elérésre? 

8 Ha igen, feltétlenül a 21-es porton kell-e lennie? 

8 Szükséges-e Anonymous elérés? 

"2 Szükséges-e, hogy a felhasználó írni is tudjon az FTP szer- 
ver mappáiba? 

"2 Melyik meghajtón található az FTP szerver gyökérkönyvtá- 

ra, leformázhatom-e azt a meghajtót akármikor? 

Milyen NTFS jogokat adjak a mappára? 

Milyen guota limitet célszerű beállítanom a meghajtóra? 

Akarok-e egy héten belül jó néhány crackelt alkalmazást 

vagy mozifilmet? 

"8 Feltelepítettem-e az összes javítócsomagot? (!) 

"8 Elég részletes-e a naplózás? (!) 


Pbod 
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IP Address: 
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21 





TF Connection: 
Í eruririeg 


G Limtedta [0 10 connections 
Connection Tímeout [// 900 seconds 
f7jEneble Logan 
; Active log format: 
fac EmendedlogFteFomat HÍ 


























5 Az FTP szerver naplózási beállításai 


Akit további részletek érdekelnek, nézzen körül a [4] címen 
és böngéssze végig a [2] címen található leírást, amely így 
kezdődik: , This documentation should not be used to exp- 
loit webservers." Én elolvastam ezt a mondatot is. 





Balássy György 
balassy 2avalon.aut.bme.hu 


A cikkben szereplő URL-ek: 


[1] http://search.support.microsoft.com/kb/c.asp 

[2] http://home.hetnet.nl/-paulus17/how2stop. deleters.txt 
[3] http://www.eeye.com/html/Products/Retina/index.html 
[4] http://www.netknowledgebase.com/forum 
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Elektronikus 


aláírás 


Végre nem kell sorba állnunk a hivatalokban, avagy mégis? 


Az elektronikus aláírás kezdetei. 

Június közepén jelent meg a magyarországi informatikai 
jogalkotás első mérföldkövét jelentő törvény az elektroni- 
kus aláírásról. Ezzel mintegy két év elmaradással követtük 
az Európai Unió jogalkotását, ahol a szabályozás keretét 
adó irányelv már 1999-ben napvilágot látott. A Magyar Köz- 
társaság és az Európai Unió között megkötött társulási szer- 
ződéssel ránk háruló jogharmonizációs kötelezettség a ma- 
gyar jogalkotási szabadságot igencsak korlátozta ezen a te- 
rületen is, így nem tehettünk mást, mint hogy átvettük az 
Európai Unióban már - és tegyük hozzá nem is rosszul - ki- 
talált normákat, kicsit megspékelve a magyar piaci sajátos- 
ságokkal. Ebből készült el a sült, amit most feltálaltak ne- 
künk, bár megízlelni csak a hatálybalépés szeptember 1-i dá- 
tumát követően tudjuk. Így most a gyakorlati próba előtt a 
törvényben leírtakkal tudunk megismerkedni. 

E cikk olvasója nyilván nálam sokkal jobban ismeri az 
aláírás technikai hátterét, így ennek részleteit mellőzve 
most csak arra mutatok rá, hogy az aláírás során a kódoló 
algoritmusos megoldást alkalmazzák. A titkos kulcs (a tör- 
vény szövege szerint: aláíráslétrehozó adat) szolgál az 
aláírásra, míg a nyilvános kulcs (aláírásellenőrző adat) arra, 
hogy a címzett azt dekódolja, és így megállapítsa, hogy az 
üzenet szövegében történt-e bármilyen változtatás. 

A törvény az elektronikus aláírás elfogadására határozott ga- 
ranciát ír elő, amikor kimondja, hogy az elektronikus aláírással 
ellátott dokumentum elfogadását - ide értve a bizonyítási eljá- 
rás során bizonyítékként történő értékelést is - nem lehet meg- 
tagadni csupán azért, mert az irat kizárólag elektronikus formá- 
ban létezik. Ez alól azonban rögtön kivételt is megállapít, a há- 
zassági és a családjog területén. További szűkítése a lehetséges 
felhasználási területnek, hogy bírósági és államigazgatási eljá- 
rásban csak akkor lehet kizárólag elektronikus dokumentumo- 
kat felhasználni, ha arra az adott eljárási jogszabály kifejezett 
felhatalmazást ad. Ez utóbbi rendelkezések gyakorlatilag 
olyannyira leszűkítik az elektronikus aláírás pillanatnyi jelentő- 
ségét, hogy azt csupán a magánjogi kapcsolatokra korlátozza. 
Egyedül csak a cégbírósági eljárásban válik lehetővé szeptem- 
ber 1-től az iratok elektronikus úton történő benyújtása. Érthe- 
tő egyrészt, hogy a bíróságok és államigazgatási szervek mai 
technikai fejlettsége nem teszi lehetővé, hogy elektronikus 
okiratokat tömegével fogadjanak, szomorú viszont ez a spanyol 
tangó szerű jogalkotás: két lépés előre, egy lépés hátra. Vagyis 
az a szép remény, hogy szeptembertől a gép előtt ülve intéz- 
hetjük ügyes-bajos dolgainkat a hivatalban történő hosszas 
sorbanállás nélkül, egyelőre csak utópia marad. Továbbra is pa- 
pírokkal felszerelkezve zarándokolhatunk a polgármesteri hiva- 
talok és bíróságok folyosóin, mindaddig, amíg azok a jogszabá- 
lyok meg nem jelennek, amelyek az eljárásokban lehetővé te- 
szik az elektronikus okiratok alkalmazását. 
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Az ügyfelek részére viszont fontos garanciát jelent az, hogy 
jogszabály nem teheti részükre kötelezővé az elektronikus 
forma használatát. 
Megkülönböztet a törvény minősített elektronikus aláírást a 
Sima" elektronikus aláírással szemben. Az előbbi olyan fo- 
kozottan biztonságos elektronikus aláírás, amely biztonsá- 
gos aláíráslétrehozó eszközzel készült, és amelynek hitele- 
sítése céljából minősített tanúsítványt bocsátottak ki. Ter- 
mészetes követelmény, hogy erre csak minősített hitelesí- 
tésszolgáltató legyen jogosult, aki az erre vonatkozó minő- 
sítést a Felügyelettől megszerzi. A fokozott biztonságú 
szolgáltatás végzését továbbá annak megkezdését megelő- 
zően 30 nappal korábban be kell jelenteni a Felügyeletnek. 
A minősített elektronikus aláírásnak a jogkövetkezmények 
szempontjából van jelentősége, mivel olyan esetben, ahol 
jogszabály valamely szerződés vagy nyilatkozat érvényessé- 
géhez az írásbeli formát kötelezővé teszi, az elektronikus 
okirat csak a minősített elektronikus aláírás alkalmazása 
esetén váltja ki a szükséges jogkövetkezményt. Így például 
adásvételi szerződést csak minősített aláírással köthetünk 
elektronikus úton. (Más kérdés, hogy jelenleg viszont nem 
lesz arra alkalmas az így megkötött szerződésünk, hogy a 
földhivatal a tulajdonjogunkat bejegyezze. ) 
Az elektronikus aláírás szolgáltatás alatt ténylegesen három 
különböző szolgáltatásról beszélünk: 

a) elektronikus aláíráshitelesítés szolgáltatás 

b) időbélyegzés 

c) aláíráslétrehozó eszközön az aláíráslétrehozó adat 

elhelyezése 

Az elektronikus aláíráshitelesítés szolgáltatás keretében a hite- 
lesítésszolgáltató azonosítja az igénylő személyét, tanúsítványt 
bocsát ki, nyilvántartásokat vezet, fogadja a tanúsítványokkal 
kapcsolatos változások adatait, valamint nyilvánosságra hozza 
a tanúsítványhoz tartozó szabályzatokat, az aláírásellenőrző 
adatokat és a tanúsítvány aktuális állapotára (különösen eset- 
leges visszavonására) vonatkozó információkat. 
Időbélyegzés során a szolgáltató az elektronikus dokumen- 
tumhoz időbélyegzőt kapcsol. Az időbélyegző tulajdonkép- 
pen semmi másra nem való, mint hogy az okirat keletkezé- 
sének időpontját hitelt érdemlően bizonyítsa. 
A szolgáltató választása szerint akár csak egy, akár több, 
vagy valamennyi szolgáltatás nyújtására is jogosult. 
A magyar törvény az európai megoldást követve nem köti meg 
különösebben a szolgáltatóvá válás feltételeit. A fokozott biz- 
tonságú, illetve minősített elektronikus aláírás szolgáltatás 
esetén már említett kötelezettségek állnak fenn. A szolgálta- 
tás végzésére minden elképzelhető vállalkozási forma feljogo- 
sítást kapott, mivel a belföldi lakóhelyű vagy belföldön tar- 
tózkodó természetes személy, jogi személy vagy jogi szemé- 
lyiség nélküli szervezet is jogosult. A törvény ilyen széles kö- 
rű megfogalmazása azt sejteti, hogy nemcsak vállalkozási, ha- 
nem nonprofit tevékenység keretében is lehet elektronikus 
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JOGI ESETEK ELEKTRONIKUS ALÁÍRÁS 
aláírás hitelesítést végezni. A közeli csatlakozás reményének 
jegyében az Európai Unió tagországaiban kiadott hitelesítést 
a magyar törvény minden további nélkül elfogadja. 

Az eddig ismertetettekből következik, hogy igazán értelme 
csak a minősített hitelesítésszolgáltatás nyújtásnak van. Az 
ezen.-a területen történő szolgáltatóvá válásnak azonban 
olyan technikai feltételei is vannak, amelynek teljesítésé- 
hez nyilván komoly díjakat kell fizetni a szükséges igazolá- 
sok és tanúsítványok kiállítása fejében. Ugyancsak jól já- 
runk mi, jogászok is, hiszen a Felügyeletnek be kell nyújta- 
ni a szolgáltatásra vonatkozó általános szerződési feltéte- 
leket és a szolgáltatási szabályzatot. Ezek megfelelő elké- 
szítése pedig a megfelelő gyakorlat kialakulásáig komoly 
úttörő jogi munkát jelent. Külön jogszabály írja elő azt a 
pénzügyi hátteret és felelősségbiztosítást, amivel a minősí- 
tett szolgáltatónak ugyancsak rendelkeznie kell. A szolgál- 
tató illetve alkalmazottja személyére vonatkozó előírások, 
mint a büntetlen előélet és a szakmai képzettség igazolása 
már csak kisebb nehézséggel jár. Látható hát, hogy nem 
kell attól félni, hogy a piacot ellepik a minősített hitelesí- 
tés szolgáltatók, hiszen a felsoroltaknak már igen kevesen 
tudnak megfelelni. A jogszabály ravasz megoldásával tehát 
nem a szolgáltatás végzésére feljogosítottak köre került 
korlátozásra, hanem a feltételeknek való megfeleléssel szű- 
kítik le a potenciális piaci szereplők körét. 

A szolgáltatót természetesen teljes körű kártérítési felelős- 
ség terheli mind a vele szerződéses kapcsolatban álló aláíró- 
val, mind azon harmadik személlyel szemben, akinek a szol- 
gáltatás szabályainak megszegésével kárt okoz. A szolgálta- 
tó azonban jogosult arra, hogy a minősített tanúsítványban, 
amelyet a minősített aláírás hitelesítésről állít ki, meghatá- 
rozza a tanúsítvány felhasználásának tárgyibeli, földrajzi 
vagy egyéb korlátait, illetve az egy alkalommal vállalható kö- 
telezettség legmagasabb értékét. Ez ugyanakkor azt is jelen- 
ti, hogy nem felel azokért a károkért, amelyeket e korlátokat 
meghaladóan kibocsátott elektronikus okirattal okoznak. 

A hitelesítésszolgáltató tevékenység befejezése esetére biztosí- 
tani kell az aláírók jogait. Így a törvény erre vonatkozóan szi- 
gorú szabályokat állapít meg: legalább 60 nappal a tevékeny- 
ség befejezését megelőzően értesíteni kell a kibocsátott és még 
vissza nem vont tanúsítványokban aláíróként megjelölt szemé- 
lyeket, valamint a Felügyeletet. Köteles intézkedni az iránt, 
hogy legkésőbb a tevékenység befejezésekor más szolgáltató 
átvegye az aláírás nyilvántartásokat. A tevékenység befejezését 
megelőzően legalább 20 nappal köteles az általa kibocsátott és 
még vissza nem vont tanúsítványokat visszavonni. 

A szolgáltatót különös kötelezettség terheli az aláírók ada- 
tainak kezelése, az adatvédelmi előírások biztosítása terü- 
letén. Csak az aláírótól közvetlenül, vagy annak előzetes 
egyetértésével gyűjthetnek személyes adatokat és csak 
olyan mértékben, ami a tanúsítvány kiállításához szüksé- 
ges. Az adatokat más célra gyűjteni vagy felhasználni tilos. 
Az elektronikus aláírás felhasználásával elkövetett bűncse- 
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lekmény alapos gyanúja estén a felderítés vagy a hasonló 
bűncselekmények megelőzése céljából, vagy nemzetbizton- 
sági érdekből a nyomozó hatóság vagy a nemzetbiztonsági 
szolgálat megkeresésére az érintett személyi azonosságát 
igazoló adatok azonban kiadhatók. Így tehát, ha a rendőr- 
ség a szerzői és szomszédos jogok megsértése miatt nyomo- 
zást indít mondjuk a BSA feljelentése alapján, az elektroni- 
kus aláírás hitelesítők újabb adatbázist jelenthetnek a sze- 
mélyek azonosítására. A szolgáltató jogosult a szolgáltatá- 
si szerződés megkötésekor okmányaink (személyi, útlevél, 
jogosítvány) megtekintésére. 

Ezek után kérdés, hogy mire jogosult az aláíró? Az aláíró jo- 
gosult az aláíráslétrehozó adatot birtokolni. Ezen túl az 
aláírónak csak kötelességei vannak: így köteles a szolgálta- 
tót haladéktalanul tájékoztatni az azonosításához szükséges 
személyazonosító adatainak változásáról, vagy az általa kép- 
viselt szervezet adatainak változásáról, az aláíráslétrehozó 
adat illetéktelen személy birtokába jutásáról vagy elveszté- 
séről, az aláírással vagy az elektronikus okirattal kapcsolat- 
ban észlelt rendellenességről, a tanúsítvánnyal ellátott 
elektronikus dokumentummal kapcsolatos jogvita megindu- 
lásáról. Az aláírót az értesítési kötelezettsége elmulasztásá- 
ból eredő károkért kártérítési kötelezettség terheli. 

Az aláíró kérheti tanúsítványa felfüggesztését vagy vissza- 
vonását. A tanúsítvány érvényességét a szolgáltató felfüg- 
geszti, vagy azt visszavonja akkor is, ha a szolgáltatással 
kapcsolatos rendellenességről szerez tudomást, megalapo- 
zottan feltételezhető, hogy a tanúsítványban foglalt adatok 
nem felelnek meg a valóságnak, vagy az aláíráslétrehozó 
adat nem az aláíró kizárólagos birtokában van, a Felügyelet 
jogerős és végrehajtható határozatában így rendelkezik, il- 
letve ha a szolgáltató tevékenységét befejezi vagy a tanú- 
sítvány érvényességi ideje lejár. 

A szolgáltatók tevékenységét a Felügyelet ellenőrzi. E kör- 
ben sok eszköz áll rendelkezésére, a helyszíni ellenőrzés so- 
rán a szolgáltató figyelmének felhívásán túl a nyilvántar- 
tásból történő törlésig. Ez utóbbi, mint legsúlyosabb szank- 
ció mellett igen érzékenyen érintheti a szolgáltatókat a bír- 
ság is, amelynek összege ötvenezer forinttól tíz millió fo- 
rintig terjedhet az elkövetett jogsértés jellegétől függően. 
Íme ez hát a szép új világ egyik jelentős vívmánya, az 
elektronikus aláírás. Bevallom, közelről számomra több aka- 
dály látszik, mint amit eredetileg elképzeltem, így félek tő- 
le, hogy az alkalmazás kezdeti időszaka nem lesz zökkenő- 
mentes. De hát a tálalást követően az étkezés ideje nem 
jött még el, így a kritikai hang is kicsit korai. Ígérem, a va- 
csora végén visszatérek a témára. 


Dr. Mayer Erika 
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a (DO programozása 


Ahogyan azt korábban megígértük, ma nyílt napot tartunk 
az ASP suliban. Olyan dologról lesz szó ugyanis, ami már 
nem kötődik szorosan az ASP programozáshoz (és ezután 
már egyre több lesz az ilyen, ,, külső" objektum), ezért a kö- 
vetkezőkben leírtakat bátran ki lehet próbálni egyszerű pa- 
rancssori scriptből, vagy akár , igazi" programozási nyelvből 
is. Az [1] címről letölthető példaprogramok a hagyomány 
kedvéért továbbra is ASP kódok, de megfelelő átalakítás (az 
objektumok létrehozása, a ki- és bemenő adatok kezelésének 
testreszabása) után más területen is használhatók. 


A CDO család 

A CDO (Collaboration Data Objects) általános feladata, hogy 
lehetővé teszi a levelezés, a hírcsoportok, és az egyes cso- 
portmunka-szolgáltatások - például naptár - programból 
történő kezelését. Ezek közül cikkünkben egyedül az egysze- 
rű levélküldésre térünk ki, akit a téma bővebben érdekel, az 
látogasson el az MSDN Library CDO mappájába [2]. Az ob- 
jektumcsalád az évek során fejlődött, egyre több taggal bő- 
vült. A legelső széles körben elterjedt verzió a CDO 1.2.1 
volt, ami az Exchange MAPI alapú levelezési és csoportmun- 
ka szolgáltatásainak kihasználását volt hivatott segíteni. Ezt 
a verziót az Exchange Server 5.5 és az Outlook 98 tartalmaz- 
ta. A CDO 1.2.1 mellett megjelent egy , butított", egyszerű- 
sített változat is, az CDO for NTS (Collaboration Data Objects 
for Windows NT Server). Ez az objektummodell az Internet 
Information Server (IIS4) telepítésével már felkerül a rend- 
szerre, így minden Windows NT 4.0-n használható, ahol az 
IIS is fut. Cikkünkben ez lesz az első objektummodell, amit 
kipróbálunk. Az Exchange és a CDO azóta jelentős fejlődésen 
ment keresztül. A CDO objektumkönyvtárak 2.0-s változata a 
Windows 2000-ben jelent meg, CDO for Windows 2000 né- 
ven (ugyancsak minden Windows 2000-ben megtalálható) . Az 
Exchange 2000 saját CDO-ja, a CDO for Exchange 2000 az 
előbbivel 1009-ban kompatíbilis, annak csak funkciókészle- 
tét bővíti ki. A CDO könyvtárak új változatai már nem a 
MAPI-t, hanem az SMTP protokollt használják. A következő 
részben a CDO for Windows 2000 lesz terítéken. 


CDO for Windows NT Server (CDONTS) 

Ez a legegyszerűbb CDO objektummodell; segítségével akár 
két sorban is küldhetünk levelet. Mindehhez azonban a szá- 
mítógépen futó SMTP szolgáltatás támogatása szükségelte- 
tik. Ha belegondolunk, nem is baj, ha egy SMTP kiszolgáló 
átveszi a vállunkról a levelek továbbításának terhét: mi csak 
kiadjuk a parancsot, az pedig jó szolga módjára elküldi a le- 
velet. A későbbi CDO verziók képesek , távoli" SMTP kiszolgá- 
lók használatára; a korábbi CDO verziók pedig helyi kiszolgá- 
ló híján hajlamosak voltak az érvényes MAPI kliens (Outlook, 
Outlook Express) segítségét kérni. Brrr. :-) Maradjunk annyi- 
ban: ha a CDONTS áldásos szolgáltatásait használni szeret- 
nénk, telepítsük a gépünkre az IIS SMTP komponensét! 
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Windows Components Wizard 


"Windows Components 
You can add or remo szzzzmzzztaat elzeezia 2000, 
Internet Information Services (IIS) SRE] 





To add or remove a component, cíck the check box. A shaded box mea 

To add or remove a c. ofthe component vil be installed. To see what s included in a componer 
Hálát Subcomponenis of Intemet Information Services (IS). 

E FroriPage 2000 Server Extensions 

57 Té intemet Information Services Snap-in 

" [0 8 Personal web Manager 











Components: 





5 OD Visual InteDDev RAD Remote Deployment Support 
220 World Wide Web Server 





Desciiption: IS sery 
Hansac  Desciptorr SMTP Service 
Total disk space regi 
EDES EE SÜS TŰT aeEk sesos tane 0.0MB 
Space avalable on disk: 2814 MB 


0 Ha telepítjük az IIS SMTP szolgáltatását, az leveszi a 
vállunkról a levélküldés terhét 


A CDONTS már önmaga is egy butított változat, de még a 
CDONTS is tartalmaz olyan objektumot, amely egymaga min- 
dent tud (persze minimális szinten). Ezt az objektumot akár 
külön is szállíthatnák, hiszen nemhogy a CDO, de a CDONTS 
más objektumaihoz sincs semmi köze. Önálló lény: hirtelen 
levélküldésre való. Akár egy sorban. Ő a CDONTS.NewMail 
objektum. Lássuk (nts1.asp): 


Dim oNewMail 


Set oNewMail - 
4 Server.CreateObject("CDONTS.NewMail") 


oNewMail.Send "feladotceg.hu", "cimzettéceg.hu", 
4 "CDONTS NewMail demo", "Hello NewMail!", o 


Set oNewMail - Nothing 


Ennyi. És működik. Négy sor, de csak mert jó gyerekek vol- 
tunk. Lássuk sorra: definiáljuk a változót, létrehozzuk a 
CDONTS.NewMail objektumot. Ezután meghívjuk az új ob- 
jektum Send metódusát, végül megszüntetjük az objektu- 
mot. Az utolsó sor fontos; a NewMail objektum tiszavirág 
életű; mindegyik példánya egyetlen levél elküldésére képes, 
azután elhaláloz. Ha újra használni szeretnénk, új példányt 
kell létrehoznunk, különben hibaüzenetet kapunk. A Send() 
metódus paraméterei a következők lehetnek: 
"8 Feladó - Az üzenet feladója. Írhatunk tisztán e-mail címet 
is, de ha akarjuk, az SMTP szabályok szerint megadhat- 
juk a feladó teljes nevét is, emígyen: 


Teszt Elek Celek€ceg.hus 
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"8 Címzett - Az üzenet címzettje(i). Ha több van, a címeket 
pontosvesszővel válasszuk el egymástól. 

"8 Téma - A levél témája (szöveges érték) 

8 Törzs - A levél törzse (szöveges érték, vagy IStream inter- 
fész, például ADODB.Stream objektum) 

"0 Fontosság - A levél fontossága. Ha normál, értéke 1, és ez 
az alapértelmezés is (ha nem adjuk meg). Ha alacsony, 
értéke 0, ha pedig magas, 2. 

A fenti paraméterek közül egyik megadása sem kötelező, 

ugyanis ha nem akarjuk egy sorban elintézni, a NewMail ob- 

jektum jellemzőit a Send() meghívása előtt szépen fel le- 
het tölteni ugyanezekkel az adatokkal (nts2.asp): 


Set oNewMail -— 
4 Server.CreateObject("CDONTS.NewMail") 


oNewMail.From z "Teszt Elek Celekéteszt.hu2" 
oNewMail.To z "Fu Beno €benotéteszt.hu2" 
oNewMail.CC z "Tar Janos Ctjaniéteszt.hu2" 
oNewMail.Bcc z "Gipsz Jakab cjgipszéteszt.hu:" 
oNewMail.Subject - "CDONTS.NewMail Demo 2." 
oNewMail.Body z "Hello NewMail !" 
oNewMail.Send 


Küldjünk csatolt fájlt a levéllel! Ehhez nincs más dolgunk, 
mint a Send() metódus előtt meghívni az AttachFile() me- 
tódust, például így (nts3.asp): 


oNewMail.AttachFile Server.MapPath("attach.txt"), 
b "ujnev.txt", 1 


Az AttachFile() metódus három paramétere a következő: 

"8 A csatolandó fájl neve. Ha a kódot ASP-ben futtatjuk, a 
Server.MapPath() segítségével keressük meg az igazi 
fájlnevet. Más esetben erre természetesen nincs szük- 
ség. Ezen kívül itt is megadhatunk IStream interfészt 
(pl. egy ADODB.Stream objektumot), ami már közvetle- 
nül a csatolandó adatokat tartalmazza. 

-8 Fájlnév a levélben - a levélben megjelenő fájlnév nem 
feltétlenül egyezik meg az eredetivel. Nem kötelező 
megadni. 

8 Kódolási mód - 0 értéke esetén UUEncode, 1 esetén Base64 
kódolással kerül az üzenetbe a csatolt állomány. Ha nem 
adjuk meg, az alapértelmezés érvényesül, ami pedig tisz- 
tán szöveges levelek esetén 0, MIME levelek esetén 1. 

Ha további fejlécinformációkat szeretnénk csatolni a levél- 

hez (például, hogy hova kell küldeni a választ) , használjuk a 

Value jellemzőt (nts4.asp): 


oNewMail.Value("Reply-To") - "valaszéteszt.hu" 


Hódít a MIME 

A levelek tartalmának további bonyolításához a MIME nyújt 
segítséget. Aki nem olvasta a magazin előző néhány számá- 
ban bemutatott MIME cikksorozatot, annak ajánlom, hogy 
vesse bele magát, mielőtt vakon tapogatózva MIME levele- 
ket kezdene készíteni. Aki olvasta, annak az elmélet után 
most talán jól jön egy kis gyakorlat :-). Egy NewMail objek- 
tum egyetlen sorral MIME levéllé alakítható (nts5.asp): 
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oNewMail.MailFormat -— 0 " MIME 

A MailFormat jellemző értéke 0, ha MIME, illetve 1, ha tisztán 
szöveges levelet szeretnénk küldeni. Ha a [3] címről letölthe- 
tő MIME Browser (vigyázat! csak Windows 2000-ren működik!) 
segítségével megnyitjuk az nts5.asp által küldött levelet, lát- 
hatjuk a MIME formátumot és a - jelenleg még egyszerű - 
felépítését is (az nts5.asp a levélhez csatol egy képfájlt is). 


BI: MIME Browser - nts5.eml 





oj xi 

File View 45 

medipant/méred  charset ; encodngi 7bt; size: 5632 — 1002) 
text/plain. (charset izo.8859.2; encoding: bit; size: 95 22) 
image/ípeg  (charset : encodng base64; size 4580 — 812) 











5 Egyszerű MIME levél, egyszerűen 


Ha már itt tartunk: küldjünk HTML levelet! Ehhez nincs más 
dolgunk, mint a levél törzsét eleve HTML-ben írni, valamint 
az eddigieket megspékelni plusz egy sorral (nts6.asp): 


oNewMail.BodyFormat - 0 " 
oNewMail.MailFormat 5 0 " 


HTML 
MIME 


Nem véletlenül két sor az a plusz egy: hiszen aki járatos a MI- 
ME-ban, tudja, hogy minden HTML levél egyben MIME levél is. 
Hiába állítjuk a BodyFormat jellemzőt 0-ra (ez jelzi a HTML 
tartalmat, ezek után az 1 nyilván a szöveges törzs kódja), ha a 
MailFormat nem MIME. Az nts6.asp a levél törzsébe ezt írja: 


oNewMail.Body 5 


4 "chisccentersEgyszeru HTML levelc/center2c/h12" 


Ha az eredményként létrejött levelet megnyitjuk a MIME 
Browserrel, érdekes dologra lehetünk figyelmesek: 


BI MIME Browser - nts6.eml 


Fde View About... 


"multipart/altermative . (charset: : encoding: 7bit: síze: 1214 7 1002) 
IEZETNUETETKETET TETTETETT KIT E] 
a text/html (charset iro:8859-2: encoding: gvoted-prinlable; size: 141." 1239 








0 A NewMail automatikusan elkészíti a HTML törzs tisz- 
ta szöveges verzióját 


Az üzenet - jó HTML levél módjára - multipart/alternative tí- 
pusú, és a HTML formátum mellett (egészen pontosan előtte) 
a törzs tiszta szöveges változatát is tartalmazza. A NewMail 
objektum tehát automatikusan elkészíti nekünk a HTML leve- 
lek szöveges komponensét, és továbbítja azt az üzenettel. 
Ezután már csak egy lényeges szolgáltatása maradt a New- 
Mail objektumnak, ez pedig a kapcsolódó komponensek ke- 
zelése. Magyarul: hogyan küldhetünk olyan HTML levelet, 
amiben a HTML oldal közepén, és nem csatolt fájlként sze- 
repel egy kép? A megoldást az nts7.asp kódban láthatjuk; a 
kulcs az AttachURL() metódus: 


oNewMail.AttachURL Server.MapPath("msgirl.jpg"), 
4 "kep.jpg" 


A metódus első paramétere a csatolandó fájl (vagy Stream, 


szokás szerint), a második pedig egy ,fantázianév". Ezt a 
nevet használhatjuk a levél HTML törzsében, ha fel szeret- 
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nénk használni a csatolt objektumot. A fenti képet tehát 
így illeszthetjük a HTML levelünk kellős közepébe: 


oNewMail.Body - 
HW "cbsbItt a kep: Ccimg src-"kep.jpg 2€/b2" 


Mindezek mellett persze semmi sem akadályoz meg minket ab- 
ban, hogy egyszerű csatolt fájlokat is hozzácsapjunk a levélhez, 
a már ismert módon. És az eredmény? A MIME cikkben bemu- 
tatotthoz hasonló, komoly (de szabályos!) MIME szörnyszülött, 
ami az ottanitól csak annyiban különbözik, hogy a levélben 
nincs digitális aláírás. Mindenesetre a struktúra meggyőző! 


zal 








multipatt/mixed . fcharset: : encodng: 7bit: size: 6423 — 10027 
A— Ég muttipart/related (charzet : encoding: 7bi: size: 5344 — 832) 
A — Ég mutpatt/altemative  (charset ; encoding: bi; size: 517 7 82) 
(ú) textelain (charzet is0-8859-2; encoding: 7bt; size: 98 229 
EJ text/himi. (charset: is0.8859-2; encoding: guoted-pintable: size: 135 7 22) 
(EH imagefpeg  (charset: : encodíng: base64; size: 4561 7 712) 
(ÉJ text/plain. (charset: ; encodng: baseS4; size: 174 — 329) 





5 NewMail in action: hát kell ennél több? 


A NewMail objektum tehát képes viszonylag összetett levelek 
létrehozására és elküldésére is. Sok mindent azonban nem 
tud: mindenekelőtt, szinte minden jellemzője csak írható (és 
nem olvasható). Nem kezeli túl intelligensen a címlistákat 
(feladó, címzettek), a csatolt fájlokat (ha egyszer csatoltuk, 
azt már nem vonhatjuk vissza) és nem utolsó sorban minden 
levélhez újra létre kell hoznunk az egész objektumot. Az ob- 
jektum képességei - a korlátai figyelembe vételével - azon- 
ban sok esetben bőven kielégítik a felmerülő igényeket. 


A CDONTS objektummodellje 


Session 
! 
Folder 
(Outbox vagy Inbox) 


Messages 
Message AddressEntry 


— Attachments —  Attachment 





—  Recipients — Recipient 


5 A CDONTS objektummodellje már komoly hierarchiára épül 


A CDONTS használatához meg kell ismernünk az objektum- 
modellt (aminek, mint látható, a NewMail objektum egyál- 
talán nem is része) . Az objektummodell részletes dokumen- 
tációja megtalálható a [4] címen. A CDONTS kommuniká- 
ció egy Session (munkamenet) objektum létrehozásával 
kezdődik. Ilyenkor , bejelentkezünk" a rendszerbe, megad- 
juk a felhasználó nevét és e-mail címét. Az itt megadott 
adatok lesznek feltüntetve a kimenő levelek feladó mező- 
jében. A bejelentkezésnek a levél küldéséhez - úgy tűnhet -, 
nincs értelme, de a valóságban szükség lehet rá, ha 
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(VIII. RÉSZ): A CDO PROGRAMOZÁSA 
Exchange környezetben dolgozunk, vagy ha esetleg nem 
levél küldésére, hanem fogadására készülünk. (A CDONTS 
segítségével belenézhetünk az IIS SMTP szolgáltatására ér- 
kezett levelekbe is!) Ilyenkor már nyilvánvaló, miért van 
szükség a bejelentkezésre. A cdonts1.asp bemutatja a le- 
vélküldés legegyszerűbb módját, e kód segítségével fogjuk 
bemutatni az objektummodell egyes elemeit. 

Első dolgunk tehát a bejelentkezés: 


Set oSession — 

HW Server.CreateObject("CDONTS.Session") 
oSession.LogonSMTP "Teszt Elek", "elekéteszt.hu" 
Létrehozunk egy Session objektumot (ez a hierarchia csú- 
csa), és meghívjuk az objektum LogonSMTP() metódusát. 
A metódus két, kötelező paramétere a felhasználó neve és 
címe (de az adatok érvényességét nem ellenőrzi a rendszer). 
Bejelentkezés nélkül a CDONTS objektummodell csaknem 
1009-ban működésképtelen. 

A következő lépés a mappa (Folder objektum) megnyitása. 
A CDONTS összesen kétféle mappát kezelhet: a bejövő (In- 
box) és a kimenő (Outbox) levelek mappáját. Ezekhez a 
Session objektum jellemzőin, illetve metódusain keresztül 
férhetünk hozzá. A kimenő postaládához például így: 


Set oFolder - oSession.Outbox 
Ez egyébként egyenrangú a következővel: 
Set oFolder - oSession.GetDefaultFolder( 2 ) 


A Session objektum GetDefaultFolder() metódusa visszaad- 
ja a paraméterben meghatározott alapértelmezett mappát. 
A paraméter lehet 1 (Inbox) és 2 (Outbox). 
Miután hozzájutottunk a mappához, az üzenetek kollekció- 
jának (Messages) megszerzése a feladat. A Folder objektum 
tulajdonképpen mást nem is tud, mint ezt: 


Set oMessages - oFolder.Messages 


A Messages objektum egy kollekció, amely Message objek- 
tumokat (azaz üzeneteket) tartalmaz. Ennek megfelelően 
is viselkedik: van Add() ,GetFirst() , GetLast() , GetPrevious() , 
GetNext() metódusa, amelyek mind-mind egy Message ob- 
jektummal térnek vissza. A Delete() töröl egy adott üzene- 
tet, a Count jellemző például visszaadja a kollekcióban ta- 
lálható üzenetek számát. 

Ha CDONTS-sel új levelet szeretnénk küldeni, akkor a kime- 
nő postaládában kell új üzenetet létrehoznunk: 


Set oNewMsg - oMessages.Add 


És ebben a pillanatban a kezünkben van az üzenetobjek- 
tum, amit nincs más dolgunk, mint rendesen feltölteni, 
majd elküldeni. Az egyszerű téma és a tisztán szöveges 
törzs még csak-csak megy: 

oNewMsg.Subject - "CDONTS Demo" 


oNewMsg.Text - "CDONTS uzenet torzse." 
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DEVELOPER ASP súLI (VIII; RÉSZ): 

... de a címzettekkel már gondunk lehet. A címzés ugyanis ki- 
csit bonyolultabb, mint eddig volt. Minden üzenet tartalmaz 
egy Recipients (, címzettek") kollekciót, ami Recipient (,,cím- 
Zett") objektumokat tárol. Nincs külön To, Cc, Bcc kollekció; 
azt, hogy egy-egy címzett éppen milyen típusú, az adott Re- 
cipient objektum határozza meg. Egy hagyományos címzett 


felvételéhez tehát fogjuk az üzenet Recipients kollekcióját: 
Set oRecipients - oNewMsg.Recipients 

... Majd a szokásos módon hozzáadunk egy új elemet: 
Set oNewRecip - oRecipients.Add 


A visszakapott objektum egy frissen létrehozott, üres cím- 

zett objektum. Ha megnézzük a Recipient objektumot, há- 

rom lényeges jellemzőt találunk: 

B Type - a címzett típusa. Értéke 1, ha To; 2, ha Cc; és 3 
ha az adott címzett Bcc. 

-8 Address - a címzett e-mail címe 

"8 Name - a címzett neve 

Ezeket a paramétereket kell kitöltenünk az újonnan létreho- 

zott Recipient objektumon, és már kész is a címzés: 


oNewRecip.Name - "Teszt Elek" 
oNewRecip.Address - "elekéteszt.hu" 


oNewRecip.Type — 1 


Ezután nincs más dolgunk, mint elküldeni az üzenetet és 
szépen kijelentkezni a munkamenetből: 


oNewMsg.Send() 


oSession.Logoff() 


Csatolt fájlok kezelése 

A csatolt fájlok kezelése hasonló a címzettek felvételéhez: 
egy-egy csatolt fájlt (legyen az beillesztett vagy ténylegesen 
csatolt adat) egy-egy Attachment objektum tartalmaz. A 
csatolt fájlokat az üzenet Attachments kollekciója tárolja. 
A kollekcióhoz az Add() metódus segítségével adhatunk 
újabb tagot. Eldönthetjük, hogy egy üres Add() hívással 
üres Attachment objektumot hozunk létre, és aztán beállít- 
gatjuk annak jellemzőit, vagy pedig egy megfelelően felpa- 
raméterezett Add() hívással ,készen szállítjuk" a csatolt 
fájlt. A cdonts2.asp példában az érthetőség kedvéért előbbi 
megoldást választottuk, de akit érdekel, böngéssze át az 
Add() metódus paraméterezését. Mindenekelőtt: ha már 
fájlokat csatolunk, állítsuk az üzenetet MIME formátumúra, 
majd következhet az Attachment létrehozása: 


oNewMsg.MessageFormat — 0 " MIME 
Set oAttachments - oNewMsg.Attachments 
Set oAttachment - oAttachments.Add() 


oAttachment.Type — 1 " 
oAttachment .ReadFromFile 


CDOFileData 


4 Server.MapPath("attach.txt") 


oAttachment.Name - "ujnev.txt" 
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A csatolmány típusa (Type) fájl (1); az üzenetben ,uj- 
nev.txt" néven jelenik majd meg. Az fájl valódi tartalmát a 
ReadFromFile() metódus tölti be az Attachment objektumba. 


HTML levelek 

HTML levél küldése az előbbiek ismeretében már nem ör- 
döngősség. Az első és legfontosabb különbség, hogy a 
HTML levél törzsét nem a Text, hanem a HTMLText jellem- 
zőn keresztül állítjuk be, valamint nem felejtjük el az üze- 
netet MIME típusúra állítani (cdonts3.asp): 


oNewMsg.MessageFormat -— 0 ! MIME 
oNewMsg.HTMLText — "cisCDONTS HTML uzenet.€/is" 


Ha pedig üzenetbe illesztett objektumot (mondjuk képet) 
szeretnénk küldeni, akkor - a NewMail objektumnál bemu- 
tatott példához hasonlóan - két dolgot kell tennünk. Elő- 
ször is, létre kell hozni egy speciális csatolt fájlt az üzenet- 
ben, amit ellátunk egy egyedi azonosítóval. Másodszor pe- 
dig, a HTML üzenet törzsében ezt az egyedi azonosítót kell 
használnunk (cdonts4.asp): 


oNewMsg.HTMLText -— 
b "cisKepet ide: cimg src-"kep.jpg"2€/i2" 


Set oAttachment 5 oAttachments.Add("kep.jpg", 
4 1, Server.MapPath("msgirl.jpg"), "kep.jpg") 


Az Add metódus általunk használt paraméterei sorrendben 

a következők: 

"8 Név - a csatolt fájl neve, ami a levélben megjelenik 

"b Típus - csatolt fájl (1), vagy csatolt üzenet (4) 

"8 Forrás - a Típustól függően vagy a csatolni kívánt fájl ne- 
ve, vagy pedig a csatolni kívánt üzenet 

"8 ContentLocation - a ContentLocation MIME fejléc; a le- 
velezőprogram az itt megadott azonosító (,.kep.jpg") 
alapján ismeri fel a HTML kódba beillesztendő csatolt 
üzenetrészt 

Ennyit a CDONTS-ről. A fenti példa elkészíti és el is küldi 

ugyan a HTML levelet, de a megvalósítás kicsit sántít. Aki 

kitalálja, hogy a cdonts4.asp és az nts7.asp miért nem azo- 

nos tartalmú levelet küld, és elküldi nekünk a megfelelő 

CDONTS kódot, nyereményre számíthat! :-) 

Legközelebb a CDO for Windows 2000 objektummodell rej- 

telmeibe ássunk bele magunkat, addig is jó levelezést! 


Fülöp Miklós 
mick Onetacademia.net 


padra erdeje TATA 


[1] http://technet.netacademia.net/feladatok/asp/8 
[21 http://msdn.microsoft.com/library/en-us/ 

s cdo/html/ olemsg overview of cdo.asp 

[3] http://technet.netacademia.net/download/MIME/ 
[6] http://msdn.microsoft.com/library/en-us/ 

s cdo/html/ denali cdo for nts object model.asp 
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AD trükkök: 
Nyomtatók 
publikálálsa 


Az Active Directory számtalan objektumtípus tárolására használ- 
ható: felhasználók, csoportok, számítógépek, nyomtatók, 
megosztott könyvtárak stb. helyezhetők el logikus, hierarchiába 
szervezett módon. Ezen objektumtípusok közül szinte mindegyik 
adja magát", könnyű őket létrehozni, megtalálni, módosítani, 
átszervezni. A nyomtatók kezelése azonban valamilyen rejtélyes 
oknál fogva nehézkesre sikeredett: a publikált nyomtató ugyan 
kereshető, de sejtelmünk sincs, hol a csudában helyezkedik el a 
hierarchiában. Elvileg telephelyek szerint is könnyedén rábuk- 
kanhatunk a hozzánk legközelebb eső printerre, de az AD nem 
kínálja fel a helyszíneket. Lássuk csak a nyomtatókeresési abla- 
kot (Start menü-sSearch. . .-2For Printers) : 
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5 A nyomtatókereső párbeszédpanel két arca. 


A baloldali ábrán jól megfigyelhető, hogy a helyszín kiválasz- 
tásában nem kapunk segítséget, míg a jobboldali arról tanús- 
kodik, hogy azért a nyomtatómeghajtók alapos munkát végez- 
nek: publikáláskor az összes tulajdonságuk (színes? kétoldalas? 
tűzőgépes?) automatikusan bekerül a címtárba. De pontosan 
hova? Ez a kérdés azért lényeges, hogy az egyes nyomtatókat 
szét tudjuk teríteni a megfelelő szervezeti egységekbe, de amíg 
nem látszódnak az Active Directory Users and Computersben 
(ADUC), addig az egérrel is viszonylag nehéz eltalálni őket :) 
Első lépésként azt kell biztosítanunk, hogy a nyomtató va- 
lóban bekerüljön a címtárba. Ezt a megosztási ablakban pi- 
pálhatjuk be (mellette balról az egyelőre használhatatlan 
Location információ): 
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5 Bal oldal: a helyszín beállítása (lásd később) jobb ol- 
dal: nyomtató publikálása a címtárba 


Ezután az ADUC megfelelő nézetének beállításával meg is 
tekinthetjük a nyomtatót a címtárban! Titka: View menü -: 
Users, Groups and Computers as containers! Magyarul: mu- 
tasd a (felsorolt) objektumokat úgy, mintha mappák lenné- 
nek, lenne bennük ez 4 az! 
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EZ fsz DEL 


És lőn. A számítógé- 
pünk alatt - sok 
egyéb mellett, me- 
lyekkel most nem 
foglalkozunk - meg- 
jelenik az imént pub- 
likált nyomtató: 


o A számítógép - mint mappa - elég sok dolgot tartalmaz 


Kezünkben az egér, és a kulcs ahhoz, hogy jobbra-balra 
hurcibáljuk a nyomtatót a címtárban. Már csak egyetlen do- 
log hiányzik a boldogságunkhoz, ez pedig a nyomtatók ke- 
resése földrajzi elhelyezkedésük szerint. Első lépésként az 
Active Directory Sites and Services (ADSS) segítségével fel 
kell vennünk a telephelyek (egészen pontosan a telephelye- 
ket alkotó IP Subnetek) evilági elnevezését. 








5 IP subnetek elhelyezése a földtekén ország/város/stb 


Jól megfigyelhető, hogy a Browse gomb szürke, azaz egyelő- 
re a rendszer nem vesz tudomást a bütykölésünkről. Hátra van 
még ugyanis a legtitkosabb lépés: a megfelelő házirend (Pre- 
populate printer search location text) engedélyezése! Javasla- 
tom szerint a legalkalmasabb hely e policy bebillentésére ma- 
ga a teljes tartomány, így biztosítható, hogy a nyomtatóloká- 
tor nem fog (látszólag) következetlenül működni. Ezután 
mars vissza a nyomtató tulajdonságai közé, ahol immár szé- 
pen világít a Browse gomb, hogy beállíthassuk a helyszínt. A 
Mi a szösz" felirat helyett immár válogathatunk az ADSS-sel 
aagxij imént felvett helyszí- 

eszes szk káloettéte nek között. Amit kivá- 
lasztunk, az válik a 
nyomtató helyszínévé, 
s erre akár kereshetünk 
is a cikk elején muta- 
tott módszerrel, hisz 
ott is megjelenik a 
Browse gomb. 





F.M. 
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WebDAV - az IIS, mint webalapú fájlkiszolgáló 
Cikkünkben az Internet Information Services 5.0 egyik új 
szolgáltatását mutatjuk be. A WebDAV (Distributed Autho- 
ring and Versioning for the World Wide Web) protokoll segít- 
ségével a webkiszolgálónk komplett fájlszerverré alakulhat 
át, megfelelő alternatívát nyújtva a biztonsági szempontból 
egyaránt kifogásolható FTP és Windows hálózati szolgálta- 
tásokkal szemben. A példák, NetMon kommunikációs nap- 
lók, demonstrációs anyagok (a cikkben dőlt betűvel szedett 
fájlok) az [1] címről tölthetők le (WebDAV mappa, olvasás- 
ra bárki megnyithatja — lehet gyakorolni :-) ). 


Mire képes a WebDAV? 

Mindenekelőtt: akit a WebDAV protokoll teljes leírása érde- 

kel, olvassa el az eredeti RFC 2518 [2] specifikációt. Cik- 

künkben röviden összefoglaljuk a WebDAV IIS5-ben megva- 
lósított funkcióit, és bemutatjuk használatát. A WebDAV le- 
hetővé teszi számunkra, hogy: 

"0 erőforrásokat, dokumentumokat kezeljünk (hozzunk létre, 
olvassunk, módosítsunk, töröljünk, másoljunk, stb.) a 
(web)kiszolgálón megosztott WebDAV-könyvtárakban 

"8 lekérdezzük, módosítsuk a dokumentumok szokásos jel- 
lemzőit (dátum, méret, stb.) 

"8 a dokumentumok egyidejű módosításának elkerülése érde- 
kében a dokumentumot a kiszolgálón zároljuk - míg egy 
dokumentum zárolt, csak olvasásra érhető el 

8 keressünk a dokumentumokban 

Teszi mindezt úgy, hogy a munka során 

"8 a HTTP protokollon keresztül működik (a szabványos por- 
ton, így a tűzfalakon általában , átmegy") 

"8 a szabványos parancsokat hét új paranccsal egészíti ki 
(ezekről később) 

"8 az adatokat korszerű XML formátumban kezeli 


Mire van szükség a WebDAV használatához? 

Természetesen szükséges egy WebDAV kiszolgáló (esetünk- 

ben az IIS5); a felhasználói oldalon pedig keresnünk kell a 

WebDAV-ot támogató alkalmazásokat. Szerencsére ilyenek 

bőven akadnak, most csak felsorolásképpen: 

"8 Maga a Windows képes WebDAV könyvtárak megnyitására. 
Windows 2000-ben a My Network Places-ben hozhatunk 
létre új helyet, ami WebDAV könyvtárra mutat (csak ír- 
juk a cím elé a http:// előtagot) 

"8 Régebbi Windows verziók (W9x, NT 4) az Internet Explo- 
rer 4 telepítése után a My Computer mappában találha- 
tó Web Folders ikon segítségével tehetik meg ugyanezt 

"8 A hamarosan megjelenő Windows XP (és egyelőre sajnos 
csak az) lehetővé teszi, hogy WebDAV mappát hálózati 
meghajtóhoz rendeljünk hozzá. A dolog egyetlen hátul- 
ütője, hogy ez a megoldás SSL titkosított (https://) 
mappákhoz nem használható 
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8 Az Office 2000 család és utódainak alkalmazásai közvet- 
lenül képesek WebDAV mappákkal dolgozni 

8 Az Internet Explorer 5.0 verziótól kezdve segíti a WebDAV 
szolgáltatások használatát. Ha egy könyvtárat nem bön- 
gészőben, hanem mappaként szeretnénk megnyitni, az 
IE File / Open ... parancsára megjelenő dialógusablakba 
gépeljük be az elérési utat, majd kattintsunk az , Open 
as Web Folder" jelölőnégyzetre. Az IE ezután a címet 
webmappaként nyitja meg (lásd a következő ábrát). 

2 Külső gyártók WebDAV kliensei, amelyek vagy közvetlen 
elérést, vagy pedig a WebDAV mappák hálózati meghajtó- 
hoz való hozzárendelését segítik - több-kevesebb sikerrel 





(Mit http://webdav.netacademia.net/mick/teszt - Microsoft internet EsBŰ 
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5 Háttérben WebDAV mappa az Internet Explorerben 
megnyitva; az előtérben a kurzor a webmappa megnyitá- 
sához szükséges jelölőnégyzetre mutat 


A WebDAV parancsok 
Mint azt már említettük, a WebDAV a szabványos HTTP csa- 
tornán kommunikál, a HTTP 1.1 [3] bővítményeként visel- 
kedik. Bár a WebDAV használatához e parancsok ismerete 
nem feltétlenül szükséges (a felhasználói felület elrejti elő- 
lünk a teljes kommunikációt), úgy gondolom, érdemes is- 
merni őket - hiszen például a webkiszolgáló naplófájljaiban 
biztosan összetalálkozunk velük. A WebDAV-os kommuniká- 
ció során szerepet kapnak az eredeti HTTP parancsok: 
"8 GET, HEAD: erőforrás, dokumentum letöltése. HEAD kérés 
esetén a dokumentum törzse nem, csak annak fejlécin- 
formációi jutnak el az ügyfélhez (ez például akkor hasz- 
nos, amikor egy fájl már a helyi gyorsítótárban van, csak 
ellenőrizni szeretnénk, hogy nem változott-e meg a ki- 
szolgálón - ilyenkor felesleges a teljes fájlt letölteni, elég 
az utolsó módosítás dátuma, vagy egy ellenőrzőösszeg). 
A HEAD parancsot a WebDAV például egy-egy fájl meg- 
létének ellenőrzésére használja előszeretettel. 
PUT: erőforrás, dokumentum feltöltése a kiszolgálóra 
8 DELETE: erőforrás törlése a kiszolgálóról. Mappák törlése 
természetesen a tartalmuk elvesztésével jár. 


b 
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-8 OPTIONS: a használható parancsok lekérdezése. 

A WebDAV ezeken kívül további parancsokat is definiál: 

6 COPY: erőforrás másolása. A másolás forrása a COPY pa- 
rancs paramétere, a cél pedig a HTTP kérésben találha- 
tó Destination fejléc értéke. Fájl és mappa egyaránt 
másolható. Példaképpen lássunk egy másolási kérést 
(copyhttp.txt): 


COPY /mick/teszt/proba.txt HTTP/1.1 
Content-Language: en-us 
Accept-Language: hu, en-us;g-0.2 
Overwrite: F 

Destination: http://webdav.netacademia.net/ 
4 mick/teszt/proba$20(2).txt 

Translate: f 

User-Agent: Microsoft Data Access Internet 
8, Publishing Provider DAV 

Host: webdav.netacademia.net 
Content-Length: 0 


Connection: Keep-Alive 


Az első sorban látható a COPY parancs, valamint annak pa- 
ramétere - a fájl, amit másolni szeretnénk. A Destination 
fejléc értéke az új fájl neve (...proba (2).txt; a szóközt URL- 
kódolásban (99020) tartalmazza). Az Overwrite: fejléc hamis 
értéke (F) azt jelzi a kiszolgálónak, hogy ha a célfájl már lé- 
tezik, ne írja felül (ilyenkor 412 Precondition Failed hiba ér- 
kezik) . Ha ez a fejléc nincs a kérésben, a cél mindig felülíró- 
dik. Vessünk egy pillantást a User-Agent: fejléc értékére. Itt 
általában a kliensalkalmazás (böngésző) azonosítója szere- 
pel; most a WebDAV kliens mutatkozik be szépen. Ne csodál- 
kozzunk tehát, ha a kiszolgáló naplójában ilyesmit találunk. 
PI MOVE: erőforrás mozgatása, fájl és mappa egyaránt moz- 
gatható. Az átnevezés is MOVE műveletet generál. A 
MOVE parancs a COPY-hoz hasonlóan működik, azzal a kü- 
lönbséggel, hogy a MOVE esetén a forrásállomány törlődik. 
0 MKCOL: új kollekció (mappa, könyvtár) létrehozása. 
"8 PROPFIND: ez a parancs a WebDAV lelke. Erőforrások tu- 
lajdonságainak lekérdezésére való, de a PROPFIND pa- 
rancs segítségével történik például a mappák tartalmának 
lekérdezése is. A kiszolgáló a választ XML formában küldi vis- 
sza. A propfindo.xml egy WebDAV mappa 0 mélységű, a 
propfind1.xml pedig egy 1 mélységű lekérdezésére adott vá- 
lasz; utóbbiban az is látható, hogy a mappa mit tartalmaz. 
"8 PROPPATCK: erőforrás tulajdonságainak (szerző, cím, 
stb.) módosítása. 
1 LOCK és UNLOCK: erőforrások zárolása és feloldása, rész- 
letesebben lásd a következő bekezdést. 


Konfliktusok nélkül 

Minden közös dokumentumtárban megoldandó probléma a 
konfliktusok (egyazon dokumentum többszörös, egyidejű mó- 
dosítása) kezelése. Mi történjen, ha egyszerre ketten nyitnak 
meg egy dokumentumot, mindketten - egymástól függetlenül 
- módosítják azt, majd elmentik? Biztos, hogy jó megoldás 
az, hogy aki később mentett, az győz? Egyáltalán nem. 

A WebDAV ezt a problémát az erőforrások zárolásával oldja 
meg. Amikor valaki szerkesztésre megnyit egy dokumentu- 
mot, zárolhatja azt (a LOCK) parancs segítségével. Ha vala- 
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ki egy zárolt dokumentumhoz próbál hozzáférni, figyelmez- 
tetést kap, és legfeljebb olvasási joggal nyithatja meg azt. 


J]Fle Edt Wiew Insert Format Iools Table Window Help 


ID 5 ggg als 3 flE ee a[o-]ala 





THE 


web.docis locked for edting 


kései (Eesseszj 


Cici Notíy to open a readronly copy of the document and [ety] 
receive notííicaton docAment is no longer Ín use. I 


5 Zárolt dokumentumot csak olvasásra nyithatunk meg 
— mondja a Word 


Amikor a felhasználó befejezi a munkát, (az UNLOCK pa- 
rancs segítségével) feloldja a dokumentum zárolását, és at- 
tól a pillanattól kezdve mások is módosíthatják azt - per- 
sze egyidejűleg mindig csak egy valaki. A felhasználónak 
egyébként ezzel sem kell közvetlenül foglalkoznia, mert az 
alkalmazás elvégzi a szükséges zárolási feladatokat. 

A dokumentumok zárolásának valódi folyamata persze en- 
nél kicsit összetettebb. Először is, minden zárolásnak van 
egy lejárati ideje, hogy ha az ügyféllel bármi történik, a 
zárolt dokumentum ne maradjon ,örökre" kalodában. Ezt 
az értéket maga az ügyfél állítja be a zárolás kérésekor, a 
LOCK parancs paramétereként átadott XML fájlban, vala- 
hogy így (lockreg.xml): 


cx?xml versionz"1.0" encodingz"UTF-8" ?5 
Sglockinfo xmlnsz"DAV:"5 
clocktype2 
cwrite /5 
€/locktype? 
cxlockscope? 
exclusive /5 
£/lockscope2 
Lownersmickc/owner5 


£/lockinfoz 


Azaz, írásra (write) és exkluzív zárolási jogot kérünk; ezen 
kívül elküldjük még a zárolás tulajdonosának nevét is (néz- 
zük csak meg a fenti ábrát!). A kiszolgáló a sikeres zárolás 
után természetesen XML-ben felel (lockresp.xml). 

Ha megnyitjuk a fenti fájlt, a válaszból látható, hogy a záro- 
lás sikeres volt. Visszakaptunk egy egyedi azonosítót, később 
ezzel hivatkozhatunk a zárolásra; a timeout érték pedig jelzi, 
hogy a zárolás 180 másodpercig érvényes. Ha a zárolást ezután 
is fenn szeretnénk tartani, a zárolást még az idő lejárta előtt 
(egy újabb LOCK paranccsal) meg kell újítani. A munka befe- 
jeztével (a dokumentum bezárásakor) a Word automatikusan 
UNLOCK parancsot küld a kiszolgálónak, ami felszabadítja az 
UNLOCK parancs fejlécében átadott azonosítójú zárolást. 


Néhány WebDAV által használt HTTP fejléc 

"8 DAV: a használt DAV séma verzióazonosítója 

"£ Depth: a legtöbb parancsnál megjelenő fejléc; értékétől 
függ, hogy a parancs csak az adott objektumra, vagy 
annak gyermekeire is érvényes. Ha értéke 0, csak az 
adott erőforrásról beszélünk; ha értéke 1, akkor az erő- 
forrásról és közvetlen gyermekeiről (a PROPFIND pa- 
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rancs például így listázza ki a mappa tartalmát) , ha pe- 
dig ,infinity", akkor a parancs az objektumra, valamint 
összes leszármazottjára érvényes. Néhány parancs alap- 
értelmezett Depth értéket használ (a DELETE például ér- 
telemszerűen az infinity-t) . 

5 Destination: a COPY és MOVE parancs használata esetén 
a másolandó erőforrás célcímét tartalmazza 

"8 Lock-Token: a zárolási azonosítót tartalmazza (UNLOCK 
parancs) 

8 Overwrite: a COPY ill. MOVE művelet esetén használt; , F" 
esetén a cél - ha létezik - nem írható felül, míg ,T" 
esetén a felülírás megengedett. 

"8 Timeout: Zárolás (LOCK) esetén itt határozhatjuk meg a 
zárolás élettartamát. 

A WebDAV teljes parancskészletének, az általa használt 

HTTP fejlécek, státuszkódok, a parancsok és válaszok tör- 

zsében található XML elemek leírása a RFC 2518 WebDAV 

[2] szabványban található meg. 


Mappák megosztása 

Ennyi alapozás után végre elkezdhetjük használni a web- 
mappákat: először azt nézzük meg, hogyan oszthatunk meg 
egy közönséges könyvtárat. Ha megnézzük a könyvtár tu- 
lajdonságlapját, észrevehetjük, hogy a fülek között a 
,Sharing" mellett szerepel egy "Web Sharing" oldal is. 


ETESZIZZETTT TESB ESEGKESEESEEZBEKBRE TT 51 
General Web Sharno ] Staro] Secuty] TTZHEKTUETEREÉ TK KERTEK KEZET] 


Donctay TETT 


Ún 
Beee E] 


(6 Dorpot shore tis folder 
e eret 








EEG] ee] Ess GT Dcsazj Ta 


5 Mappa megosztása 


Egy mappát több néven (sőt, ha a kiszolgálón több web léte- 
zik, több weben is) megoszthatunk. A jobboldali ábrán lát- 
ható dialógusban meghatározhatjuk, hogy a mappa milyen 
néven, milyen jogosultságokkal tűnjön fel a webkiszolgálón. 
Az első és legfontosabb a mappa saját NTFS biztonsági beál- 
lítása - a mappa tulajdonságlapjának a Security oldalán ál- 
líthatjuk be. Ellenőrizzük az itt megadott jogokat, mert az 
Everyone - Full Control alapértelmezés nem tartozik a biz- 
tonságos beállítások közé. Ha az anonymous hozzáférést en- 
gedélyezni szeretnénk, adjunk megfelelő jogokat az 
IUSR cszámítógépnév: felhasználónak. Ezután következhet 
a globális, egész mappára érvényes WebDAV hozzáférési jo- 
gosultságok beállítása, amelyek a következők lehetnek: 
"8 Read - a mappa WebDAV felületen keresztül olvasható 
"0 Write - a mappa tartalma WebDAV felületen keresztül írható 
"0 Directory Browsing - a mappa tartalma WebDAV felüle- 
ten keresztül böngészhető 
"0 Script Source Access - hozzáférés a futtatható fájlok tar- 
talmához. Ha ezt nem engedélyezzük, az Execute Permis- 
sions alatt beállított állományok nem letöltődnek, ha- 
nem a kiszolgálón végrehajtódnak. Az Execute Permissi- 
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ons None értéke esetén ennek beállítására nincs szükség, 
a mappa teljes fájlkiszolgálóként üzemel. Ha a WebDAV 
könyvtárunk egyben ,hagyományos" web része is, szük- 
ség lehet a scriptek futtatására, ilyenkor az Execute Per- 
missions értékét állítsuk Script-re, és a Script Source Ac- 
cess-t pedig engedélyezzük. Ha az Execute Permissions 
értéke nem None, és a globális jogosultságok között az 
írás (Write) is engedélyezve van, legyünk nagyon óvato- 
sak a mappa NTFS jogainak beállításaival. Hibás beállítás 
esetén ugyanis előfordulhat, hogy a felhasználó képes 
bármilyen fájlt feltölteni, majd futtatni a kiszolgálón! 
Akinek ezek a beállítások valahonnan már ismerősek, nem 
téved: az előbbiekben virtuális alkönyvtárt hoztunk létre a 
webkiszolgálón. 





Vital Dirocia ] Documerts ] Dirociny Seaisiy [HTTP Hozdere ] Custom more] 
"When comecánag tó this rosölaoe. the content thosád come hont 
G A dírectory located on this computer 





Statng 
ege Contigurotion... 
Execute Perméssions  [None . 

[eles Ptasaon [meőmtfoseg Ze] 


Deladt Web Ses Wwebdav. 


5 A webmappa megosztása nem más, mint egy virtuális 
alkönyvtár létrehozása 


Az IIS konzolban magunk is létrehozhatunk új alkönyvtára- 
kat, vagy ellenőrizhetjük, módosíthatjuk a meglévők beállí- 
tásait. Miután pedig a WebDAV mappák tulajdonképpen az 
IIS web alkönyvtárai, a velük végzett műveletek bekerülnek 
az IIS naplójába. 


Hozzáférés a webmappákhoz - az ügyféloldal 

Az ügyfél feladata ezután már csak az, hogy csatlakozzon 
ezekhez a megosztott mappákhoz. A webmappák megnyitá- 
sát Internet Explorer-en keresztül a cikk elején már egy kép 
erejéig bemutattuk (File / Open / Open as Web Folder). Ha 
meguntuk mindig kézzel begépelni a megnyitni kívánt cí- 
met, a My Network Places alatt létrehozhatunk állandó hi- 
vatkozást is. Az ,Add Network Place" ikonra kattintva elin- 
dul a varázsló, amely néhány lényegre törő kérdés után lét- 
rehozza nekünk a kívánt parancsikont: 






















e 
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Usa this folder tó open fdes and 
fokdezt on other comoszers mát 
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5 Webmappa-hivatkozás a My Network Places alatt 
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Miután ezt a hivatkozást létrehoztuk, a mappa a fájlrend- 
szer részévé válik. Windows 9x és Windows NT 4.0 esetén 
az eljárás hasonló, ott - legalább Internet Explorer 4.0 te- 
lepítése után - a My Computer alatt keressük meg a Web 
Folders ikont. Sajnos a webmappákhoz egyelőre nem ren- 
delhetünk hálózati meghajtót, így pl. a DOS-os alkalmazá- 
sok nem részesülhetnek az előnyökből, de ez már nem tart 
sokáig: jön a Windows XP, ahol redmondi barátaink már 
megengedik, hogy hálózati meghajtóhoz WebDAV mappát 
rendeljünk. Tessék csak nézni: 


EZEL 


icrosoft Windous XP [Wersion 5.1.26881 
KC) Copyright 1985-2981 Microsoft Corp. 


:Nnet use t: http://webdav.netacademia.net/mick/teszt 






ter the user name for "webdav.netacademia.net": mick 
nter the password for webdav.netacademia.net: 
he command conpleted successfully. 


5 Szentségtörés Windows XP-ben: net use és http ?! 


Természetesen nem kötelező mindezt parancssorból művel- 
ni, használhatjuk a Map Network Drive varázslót is: 


Map Network Drive 


"Windows can help you connect to a shared network folder 
and assign a drive letter to the connection so that you can 
access the folder using My Computer. 


Specify the drive letter for the connection and the folder 
that you want to connect to 


Drive: ÍT: v 
Folder:  [dttp://mebdav.netacadom ] ( growse.. 














Example: tiservertshare 
(E Reconnect at logon 
Connect using a different user name. 


Sian.up for online storage or connect to a 
Detwork server. 





5 Map WebDAV Drive :-) 


Említettük azt is, hogy az Office alkalmazások teljeskörű 
WebDAV-támogatást tartalmaznak (a FrontPage például a 
kiszolgálóhoz való csatlakozáskor ellenőrzi, hogy a WebDAV 
rendelkezésre áll-e, és ha igen, akkor a saját fájlátviteli pro- 
tokollja helyett ezt használja). Ha például egy Word doku- 
mentumot webmappába szeretnénk menteni, ne haboz- 
zunk, adjuk meg az elérési utat és hajrá! 








Fiename:  ttp:ffwebdav.netacademia.netjmiekítesztfebdav.doc 7] 
Save as type: [word Document (".doc) s Carcel 


5 Az Office alkalmazások 2000 óta WebDAV-kompatibi- 
lisek 
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A WebDAV kommunikáció biztonsága 

Két fő területet kell megvizsgálni: a felhasználóazonosí- 
tást, valamint az átvitt adatok biztonságát. A felhasználó- 
azonosítás megegyezik az IIS beépített felhasználóazono- 
sítási módszereivel; ha Internet Explorer-t használunk, a 
beépített Windows felhasználóazonosítás valamelyest biz- 
tonságosnak mondható (mindenesetre biztonságosabbnak, 
mint például az FTP protokoll nyílt jelszavas azonosítása). 
Az átvitt forgalom alapértelmezésben nem titkosított. 
Azonban mind az IIS, mind a böngésző lehetővé teszi az SSL 
kapcsolatok használatát (ezek kiszolgálóoldali telepítéséről 
következő számunkban lesz szó). Ha tehát egy https:// web- 
mappa a rendelkezésünkre áll, azt minden további nélkül 
megnyithatjuk, használhatjuk, miközben mind a felhaszná- 
lói, mind az átvitt adatok biztonságban vannak. Ehhez 
mindössze annyit kell tennünk, hogy a megnyitandó WebDAV 
mappa elérési útjába http:// helyett https://-t írunk (Win- 
dows XP-n https:// webmappához sajnos nem rendelhetünk 
hálózati meghajtót, de minden más módszer működik ott is). 





KAZE L Ea gu uaz a 
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5 Titkosított WebDAV kapcsolat egy kattintással 


Fülöp Miklós 
mick Enetacademia.net 


[1] http:// et adi vnloat V 
[2] http://www. 
[3] http://www. 
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DEVELOPER 


Fuss Forrest, fuss! 


- avagy SOL lekérde- 
zések optimalizálása 


Bevezetés 

Többen kérték, hogy írjak az SOL Server lekérdezések teljesít- 
cem, pont emiatt vissza is kell fognom magam. Rengeteg 
Ouery Tuning-ról találhat cikket a kedves olvasó a Microsoft 
website-ján, amelyeket nem akarom megismételni, a cikk vé- 
gén található URL-ekre elevickélve bárki elolvashatja őket. 
Inkább ad-hoc jelleggel olyan optimalizáláshoz kapcsolódó 
ismereteket (is) szeretnék megosztani a Kedves Olvasóval, 
amivel nem nagyon fog találkozni a megadott linkeken. 


A mindent eldöntő indulás: a tervezési fázis 

A tervezési szakasz az, ami a legnagyobb befolyást gyako- 
rolja az elkészült adatbázis használhatóságára és sebessé- 
gére. Általában nagyon nehéz egy, a tervezés során elron- 
tott adatbázisból épkézláb teljesítményt (és adatokat) ki- 
hozni, ezért különösen hangsúlyos a teljesítményhangolás 
szempontjából a megfelelő kiindulási alap. 

Minden adatbázis élete úgy indul, hogy megszületik az 
igény: bizonyos üzleti adatokat adatbáziskezelő program 
segítségével, struktúrált módon szeretnének tárolni. A ke- 
zelendő adatoknak általában van egy belső logikája, ami 
magából a kiinduló üzleti folyamatból következik. Az adat- 
bázis tervezése során összegyűjtjük a modellezendő valódi 
vagy fogalmi szinten létező objektumokat (entitiásokat) , és 
ezeket relációs adatbázisokban táblákkal modellezzük. Az 
entitások tulajdonságait a táblák oszlopaival írjuk le. A va- 
ló életről adatbázisra történő leképezés eléggé intiuitív fo- 
lyamat, és ha ugyanazt a problémát több ember, egymástól 
függetlenül elkezdi modellezni, valószínű, hogy hasonló, de 
nem teljesen azonos adatbázisokat kapunk eredményül. Ez 
általában nem probléma, mert legtöbbször első körben még 
nem a végleges struktúrát alkotjuk meg. 

Az entitások azonosítása után látunk neki az adatbázis nor- 
malizálásának, melynek célja a redundancia eltávolítása az 
adatok funkcionális függőségének elemzésével, a táblák mó- 
dosításával és új táblák bevezetésével. A normalizálási folya- 
matnak több lépcsője van, melyeket normálformáknak hívunk, 
és 1-től 5-ig számozzuk őket. Általában a 3-as vagy afeletti 
állapotban levő adatbázisokat normalizáltaknak hívjuk. 

A normalizálási folyamat vége általában még nem végállo- 
más. Egy normalizált adatbázisban kevés redundáns infor- 
máció van, így optimális a tárolási igénye, viszont az ada- 
tok nagyon sok táblára vannak szétosztva. Ez előnyös a mó- 
dosítások szempontjából, mert a táblák sorai rövidek, így kis 
adatmennyiségekkel kell az SOL Servernek foglalkoznia, és 
egy adatlap (8k) felolvasásával sok információt el tud érni 
a kiszolgáló. A módosításokra optimalizált adatbázisokat 
Online Transaction Processing (OLTP) rendszereknek hívjuk. 
Egy normalizált alkalmazás majdnem kész erre a működésre. 
A gyakorlatban természetesen nincsnek tisztán OLTP adatbázi- 
sok, hisz mit érünk egy olyan adatbázissal, amibe csak lapátol- 
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juk befelé az információkat, de sose olvassuk ki őket onnan? A 
másik adatbázistípus, amiben ritkán történnek módosítások, vi- 
szont az adatokat sokszor és sokféle szempont szerint kérdezik 
le: Decision Support System (DSS) a nevük. Az SOL Server OLAP 
szolgáltatása ezt a fajta működést támogatja. 

DSS elemzés céljára általában nem ideális egy normalizált 
adatbázis, mert a lekérdezések csak sok JOIN árán tudják 
összeszedni a szükséges információkat, azaz általában las- 
súak lennének. Ilyenkor nyúlunk a denormalizáláshoz, 
amely során mesterségesen viszünk be némi rendundanciát 
az előzetesen már normalizált adatbásunkba. Így ugyan ne- 
hézkesebbé és lassúbbá válik az adatok módosítása, de a le- 
kérdezések sokkal gyorsabbakká válhatnak, köszönhetően 
az előre kiszámolt (redundáns) adatoknak. 

A hétköznapi adatbázisok általában félig OLTP, félig DSS mű- 
ködésűek, azaz vannak benne olyan információk, amelyeket 
sűrűn módosítanak, és vannak, amelyeket sűrűn kérdeznek le. 
Ha a kétféle igény által érintett táblák különbözőek, akkor 
nincs nagy gond, a DSS rész által igényelt lekérdezésekhez 
hangolva denormalizáljuk az adatbázis ezen részét, míg a gyak- 
ran módosított részeket meghagyjuk normalizált állapotban. 
A gyakorlatban sajnos a kétféle funkciót sokszor ugyanazon 
táblákon kell megvalósítani. Ilyenkor jönnek a kompro- 
misszumos megoldások, és megpróbáljuk az időket úgy 
szétosztani, hogy a lekérdezések eléggé gyorsak legyenek, 
de a módosítások is lefussanak elfogadható idő alatt. 

Az eddigiekből következő nagyon fontos tervezési szem- 
pontok: 


Egy jól teljesítő adatbázis tervezéséhez nem elég az en- 
titások pontos azonosítása és modellezése, hanem figye- 
lembe kell venni a várható terhelés jellegét is. Mely en- 
titások mely tulajdonságát fogják sűrűn módosítani? Mi- 
lyen adatokat kérdeznek le sűrűn? Milyen jellegű adato- 
kat kell sűrűn aggregált eredményként visszaadni? 


Ezen információk kinyerhetők az üzleti követelményekből. 
Meg kell tudjuk előre mondani, mely táblákat fogják napon- 
ta többezerszer módosítani. Át kell gondolni, melyek lesz- 
nek azok a lekérdezések, amelyeknek a végrehajtása időkri- 
tikus lesz, mert például emberek fogják felhasználni a kime- 
netét, és nekik fontos a gyors válaszidő. 

Remélem az eddigiekből már látszik, hogy a jó adatbázister- 
vezés legfontosabb feltétele, hogy jól ismerjük a modellezen- 
dő folyamatot, és így azokat a részeket optimalizáljuk már a 
tervezési fázisban, amelyeket sűrűn használnak, vagy nagyon 
szem előtt vannak. Ha egy éjszakánként generálódó riport 
generálását sikerül 4 óráról 3 órára felgyorsítani lehet, hogy 
megdícsérnek, de igazából az senkit nem érdekel. De ha az 
ügyfélszolgálatnál egy keresés idejét lehúzzuk mondjuk 3 
másodpercről 0.5 mp-re, akkor nagyon sok hálás hangot fo- 
gunk hallani. Ez nem tisztán mérnöki munka. Nem lehet azt 
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mondani, hogy egy adatbázis úgy van tervezve, hogy a le- 
hető leggyorsabb legyen (sokszor ez a kérés). Azt lehet ki- 
jelenteni, hogy ebben az adatbázisban az ilyen és ilyen jel- 
legű terhelés esetén optimális válaszidőket fogunk kapni. 
Ebből következik, hogy ha menet közben akár mi, akár más 
továbbfejleszti a rendszerünket a kibővült vagy megválto- 
zott üzleti igényeknek megfelelően, akkor az optimális ter- 
vünk lehet, hogy elkezd köhögni és lassulni. Ilyenkor in- 
dexekkel és néhány egyéb trükkel még lehet, hogy utána 
tudjuk húzni az adatbázist, de előbb-utóbb eljön az a 
pont, amikor nincs mit tenni, az új igényeknek megfele- 
lően az alapoktól át kell tervezni a rendszert. Ez általában 
fájdalmas döntés, de az elhalogatott döntés miatt bekö- 
vetkező üzemzavar általában nagyobb visszhangot kelt. 


Az adatbáziskezelő termék kiválasztása 

A tervezési fázisban még nem nagyon beszéltem konkrét 
termékről, mert a tervezés első (logikai) részében még nem 
érdekes, hogy milyen relációs adatbáziskezelőn fog futni az 
adatbázisunk. Azonban a második, fizikai tervezési szakasz- 
ban meg kell határoznunk egy konkrét adatbáziskezelő ter- 
méket, és annak lehetőségeire építve megvalósítani az adat- 
bázist. Ha azt a feladatot kapjuk, hogy írjuk minnél jobban 
hordozhatóra az adatbázist, akkor kevesebb lehetőségünk 
marad a teljesítményoptimalizálás figyelembe vételére, míg 
egy konkrét termékre specializálva általában sok eszköz a 
rendelkezésünkre áll. A következő fejezetekben vizsgáljuk 
meg, hogy egy jó, a megfelelő helyeken denormalizált adat- 
bázis esetén milyen háttér áll a szolgálatunkra, ha SOL Ser- 
ver 2000-en akarjuk az adatbázist megvalósítani. 


Általános irányelvek SOL Serverhez 

Rövid sorok 

Az SOL Server 2000 8 kByte-os lapokon tárolja a táblák so- 
rait. Ha egy tábla sorai rövidek, akkor egy lapra sok fér, így 
az SOL Server sok sort ki tud nyerni egy lapból, azaz keve- 
sebb IO művelettel jár az adatok kiolvasása. A hosszú sorok 
másik hátránya, hogy mivel nem nyúlhatnak át a lapokon, 
sok lap nem lesz teljesen kihasználva. Például két, egyen- 
ként 3 kByte-ot tartalmazó sor mellett kimarad 8-6-2 
kByte-nyi hely, amelyet a sorok eléréséhez teljesen feleslege- 
sen fel kell olvasni a lemezről. Egy normalizált adatbázis ál- 
talában sok, keskeny, azaz kevés oszlopból álló táblából áll, 
így azokat az SOL Server hatékonyan tudja tárolni és kezelni. 


Rövid kulcsok 

Bár az SOL Server megengedi akár 900 byte-os kulcsok lét- 
rehozását is, ne éljünk a lehetőséggel. Az elsődleges kul- 
csok legyenek minél rövidebbek, a legjobb, ha számok, 
vagy néhány karakteres szövegek. JOIN-ok során a hosszú 
kulcsok összehasonlítása jelentős időbe kerülhet, ami to- 
vább lassítja a lekérdezéseket. 

Mivel az elsődleges kulcs létrehozása során mindig létrejön 
egy index is a kulcsként definiált oszlop(ok)on, és ez alap- 
értelmezésben egy CLUSTERED index, azért különösen fon- 
tos, hogy rövid legyen a kulcsunk. A Clustered index kulcsa 
megjelenik ugyanazon tábla ÖSSZES NonClustered indexében 
is, ezért a nagyobb méret az összes index hatékonyságát le- 
rombolhatja. (Érdemes elgondolkodni azon is, hogy egyetlen 
Clustered indexünket mire , pazaroljuk", mert ez az indextípus 
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tartománykeresésekre a legalkalmasabb. Mit szoktunk ilyen 
formán lekérdezni? JOIN-ban a gyermekrekordokat!) 


Válaszidő vagy végrehajtási idő? 

Ha ki kell listáznunk egy felhasználó részére tízezer sornyi 
információt (amiből jó, ha egyszerre ötvenet lát), akkor mi 
a lényeg: az, hogy az összes sor minél gyorsabban lejöjjön, 
vagy az, hogy az első lapnyi (50) sort minél gyorsabban 
megkapja? Mivel ember ül a számítógép előtt, neki bőven 
elég, ha az Enter leütése után kap valami infót, amit néze- 
gethet. Csakhogy az SOL Server pont ellentétesen gondol- 
kodik! A kiszolgáló olyan stratégiával hajtja végre a lekéde- 
zéseket, hogy azok minél gyorsabban kész legyenek! 
Tegyük fel, hogy egy rendezett listát generáltatunk, és a 
rendezendő oszlopra pont van egy nonclustered indexünk. 
Sok sor esetén az SOL Server nem fogja az indexet használ- 
ni, hanem inkább végigolvassa a teljes táblát, mert az 
gyorsabb. Így bár mondjuk 5 másodperc múlva ránkzúdítja 
a 10000 sort, de 5 másodpercig nem történik semmi, mert 
addig nem ad vissza semmit, amíg le nem rendezte a tel- 
jes eredményhalmazt. Ezzel szemben, ha például indexet 
használna, akkor lehet, hogy akár 20 másodpercig is eltar- 
tana a lekérdezés, de az index által megvezetett olvasás 
következtében már az első sor visszaolvasása után el tud- 
ja kezdeni visszaadni az eredményhalmazt, mert , magától" 
rendezve jönnek az adatok, nem kell utólag rendezni. 
SOL Server esetén az OPTION (FAST n) opcióval - ahol az n 
a gyorsan elérni kívánt sorok száma - lehet elérni, hogy a 
kiszolgáló olyan hozzáférési stratégiát használjon, ami le- 
het, hogy nem a leggyorsabb végrehajtást eredményezi, de 
az első n sort gyorsan vissza fogja adni. 


DBCC DROPCLEANBUFFERS 
SELECT $ FROM [Order Details] 


ORDER BY ProductID 


A lekérdezés végrehajtási terve: 





Fő. SOL Gery Analyzer - [Ouery - csharp.Northwind.DOTNETVsoci - Untitled51] 
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Azaz látható, hogy egyszerűbbnek találta a kiszolgáló vé- 
gigolvasni a táblát, és azután lerendezni a sorokat, semmint 
hogy használja a ProductID-n található nonclustered indexet. 
Ha megkérjük, hogy az első száz sort nagyon gyorsan adja: 


DBCC DROPCLEANBUFFERS 


SELECT $t FROM [Order Details] 
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ORDER BY ProductID 
OPTION (FAST 100) 


akkor más végrehajtási tervet kapunk, amely már használja 
a nonclusted indexet: 


IDE 
döl 
l1d-SHöElrmagálolma-]v ) a IJÜ Notnwna 7]: 


SELECT " FROM (Order Details) 

ORDER BY ProductID 

OPTION (FAST 100) z] 
, 


Ouery 1: Ouery cost (relatíve co che batch): 100.00£ 
Ouery text: SELECT ! FROM (Order Details]) ORDER BY ProductID 0 


es e 


SELECT Bookmark Lookup Order Details.P... 
Cost: Oz Cost: 5Zr Cost: 484 
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A DBCC DROPCLEANBUFFERS célja, hogy a mérések előtt kidobál- 
ja a felolvasott lapokat a buffer cache-ből, így a táblát illetve az 
indexet mindig lemezről kelljen felolvasni. Így reálisabb az 
összehasonlítás, nem befolyásolja a cache pillanatnyi állapota. 
Kedvenc eszközünk, a Ouery Analyzer ennél több informá- 
ciót is ad nekünk, ha bekapcsoljuk a Show Server Trace és 
a Show Client Statistics eszközöket, amelyek a Ouery menü- 
pont mögött laknak. 

A Server Trace lekérdezésünkre vonatkozó információit 
összefoglaltam a következő táblázatban: 





Text pitét (ej lel AV] L(tGEj Mat 
SELECT cse 209 60 28 0 
SELECT ... OPTION 231 60 224 0 
(FAST 100) 


Látszik, hogy a FAST 100 hatására a lekérdezés 209 msec 
helyett 231-re nőtt, ami az indexen keresztüli adatbejárás 
224 logikai lapolvasása miatt van. Jelentősebb számú 
(210000) sor esetén nagyobb lenne a különbség. 

Sajnos pont a lényeget nem tudom demonstrálni, ami azt mu- 
tatná meg, hogy a második esetben az első néhány sort tar- 
talmazó hálózati csomag sokkal hamarabb érkezik meg, mint 
az első esetben. Egy egyszerű ADO alkalmazással ezt is ki le- 
hetne mérni, ez házi feladat a Kedves Olvasóknak. A jó ötle- 
teket várom a fejlesztői levelezési listánkon, bögrés feladat :) 


Tárolt eljárások 

Az egyik ,legolcsóbb" teljesítménynövelő eszköz, mégis sokan 
nem élnek vele. Miről is van szó? Egyszerűen arról, hogy az 
alkalmazásunk működéséhez szükséges lekérdezéseket csoma- 
goljuk be egy tárolt eljárásba, és a működtetéshez szükséges 
paramétereket emeljük ki a tárolt eljárás paraméterlistájába. 
Miért gyorsabb egy lekérdezés végrehajtása, ha az tárolt eljá- 
rásban van elhelyezve? A titok nyitja akkor tárul fel, ha meg- 
nézzük, hogyan hajt végre az SOL Server egy SOL parancsot. 

A végrehajtás első lépésében a kiszolgáló nyelvi elemzést 
végez a kapott parancson, azaz megnézi, hogy nyelvtanilag 
megfelelő Transact SOL kódot adtunk-e neki. Sikeres elem- 
zés után a parancsokat átalakítja egy belső bináris reprezen- 
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tációvá, amit seguence tree-nek hívnak. Ezt követi egy nor- 
malizációs folyamat, amely kifejti a hivatkozott view-kat, 
belerakja a fába az implicit konverziók parancsaival együtt. 
Ha a kapott SOL parancs egy adatmódosító parancs 
(UPDATE, DELETE, INSERT), akkor a seguence tree-ből egy 
guery graph-ot képez a kiszolgáló, amelyet az optimizer, az 
SOL Server esze fel tud dolgozni. Az optimizer az eloszlási 
statisztikák, maga a lekérdezés és az indexek alapján lege- 
nerál egy általa leghatékonyabbank ítélt végrehajtási tervet. 
Ez a hosszú folyamat előzi meg a parancs valódi végrehajtá- 
sát. Mielőtt azonban a végrehajtás megkezdődne, egy igen 
fontos lépés zajlik le. A kiszolgáló eltárolja végrehajtási ter- 
vet a procedure cache-ben (ami egyébként a buffer cache ré- 
sze), hiszen lehet, hogy legközelebb mégegyszer futtatni 
akarják ugyanezt a lekérdezést, és akkor már nem kell lege- 
neráni a végrehajtási tervet. A tárolt eljárásokba be nem cso- 
magolt lekérdezéseket általában ad-hoc (magyarul talán csip- 
csup) lekérdezéseknek hívjuk. Ezeket az SOL Server nem szí- 
vesen rakja be a cache-be, hisz viszonylag kicsi a valószínű- 
sége, hogy az utolsó bitig ugyanazt a lekérdezést valaki újra 
végrehajtsa. Emiatt az ad-hoc lekérdezéseket a legtöbb vég- 
rehajtás során újra kell fordítani, azaz lassúak lesznek. 
Teljesen más a helyet a tárolt eljárásokkal. Ők kifejezetten 
arra vannak kihegyezve, hogy a végrehajtási tervük a proce- 
dure cache-ben lakjon, így általában a tárolt eljárások végre- 
hajtási tervét ritkán fordítja újra a kiszolgáló. Azaz kimarad 
sok időigényes lépés, egyszerűen csak végre kell hajtania a 
kiszolgálónak a korábban elkészített tervet. Ez lekérdezések- 
től függően több tíz vagy több száz százaléknyi teljesítmény- 
növekedést jelenthet, és szinte nem kell érte tenni semmit! 
Érhetnek azonban bennünket meglepetések. Berakunk több SOL 
parancsot egy tárolt eljárásba, hogy majd jól felgyorsulnak, a 
fordítási lépés kihagyása miatt. Végrehajtjuk az eljárást, és ki- 
derül, hogy az még akár lassabb is lett, mintha közvetlenül le- 
futtattuk volna egy batch-ben a részparancsokat. Mi történt? 
Az SOL Server a tárolt eljárás végrehajtásának kezdetén készít 
egy tervet, amelyben benne foglaltatik az eljárás összes paran- 
csa. Elkezdi a végrehajtást, és egyszer csak találkozik egy olyan 
paranccsal, ami alaposan belenyúl az adatbázisba, például lét- 
rehoz egy indexet valamelyik táblán. Ekkor az SOL Server azt 
mondja, hogy volt jó terv, nincs jó terv, hiszen az új index 
miatt lehet, hogy sokkal hatékonyabban is le lehetne futtatni 
a maradék parancsokat. Kidobja a meglevő tervét, és újrafordít- 
ja a tárolt eljárást, a-tól 2-ig, majd folytatja a végrehajtást ott, 
ahol abbahagyta, csak már az új tervnek megfelelően. 

Egy eljárás futtatása során akár többször is újrafordulhat az 
egész eljárás, amiből mi nem látunk semmit, csak azt, hogy 
lassú a végrehajtás. Az SOL Server Profiler segítségével meg- 
jeleníthetjük az újrafordítási eseményeket is, így egy gyanús 
rendszert érdemes a profilerrel működés közben megnézni. 
Ha azt látjuk, hogy egyes tárolt eljárások futtatásuk során 
többször is újrafordulnak, akkor meg kell néznünk mi az oka, 
és azt meg kell szüntetni. A pontos okokat és azok feloldá- 
sát az [1] címen található tudásbázis cikk részletezi. 

Mikor érdemes gyanakodnunk az újrafordításokra? A legalapve- 
tőbb okok az átmeneti táblák használata, és a DDL és DML pa- 
rancsok keverése, azaz például létrehozunk egy táblát (DDL), 
majd módosítunk egyet (DML). A legtöbb újrafordítási problé- 
mát a sorok átrendezésével könnyedén meg lehet oldani, de a 
hivatkozott cikkben a bonyolultabb eseteket is ismertetik. 
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Denormalizálás 

A tervezésnél már említettem, hogy a DSS rendszerekben me- 
sés eredményeket érhetünk el a denormalizálás alkamazásá- 
val, azon az áron, hogy az adatmódosítások lassabbak lesz- 
nek. Nézzük meg, hogy SOL Server 2000 esetén milyen eszkö- 
zök könnyítik meg a denormalizált adatok kezelését. 

Tegyük fel, hogy kereskedelmi rendszerünkben (Northwind) 
nagyon gyakori az típusú a lekérdezés, amelyben a vásárlások 
által megmozgatott pénzmennyiségekre kíváncsiak. A norma- 
(izált adatbázison így nézne ki a feladatot végrehajtó parancs: 


SELECT 
OrderID, 
SUM(Ouantity ! UnitPrice § (1-Discount)) 
FROM [Order Details] GROUP BY OrderID 


Természetesen az aggregálás nagy adattömegek esetén na- 
gyon időigényes tud lenni, valahogyon előre ki kellene 
számítani és eltárolni az aggregált eredményeket (ezzel vi- 
szünk be redundanciát) , és utána a lekérdezésben felhasz- 
nálni a kész eredményeket. 

Mit tehetünk a gyorsabb lekérdezés érdekében? Például ír- 
hatunk triggert, ami egy másik táblában nyilvántartja a 
részösszegeket az OrderID alapján. A trigger az alaptáblán 
történt minden egyes adatmódosítás esetén kiszámolja a 
módosított összeget, és azt módosítja a gyorsítótáblában. 
Egy ilyen trigger írása nem is olyan egyszerű! 

Tegyük fel, hogy a tábla szerkezete a következő: 


CREATE TABLE GyorsSzumma ( 
OrderID INT NOT NULL PRIMARY KEY CLUSTERED, 


Szumma money NULL ) 


A módosításokat átvivő trigger működése szavakban: 
"8 INSERT és UPDATE esetén: nézzük végig az összes módo- 
sított vagy beszúrt sort. Minden egyes érintett Order- 
ID alapján számítsuk ki az összegeket, és azt tároljuk el 
a segédtáblánkban. Az egész eljárás problémás pontja 
az előbbi mondat , tárolni" igéje. Ugyanis ez attól füg- 
gően, hogy az adott OrderID-jú szumma létezik-e a se- 
gédtáblában vagy UPDATE-et, vagy INSERT-et jelent. 
"1 DELETE esetén: ha még létezik ugyanezzel az OrderID-val 
más tétel is az alaptáblában, akkor nincs más dolgunk, 
számoljuk ki az összeget az alaptáblában a törölt so- 
rokban található OrderID alapján, és módosítsuk a se- 
gédtáblát. Ha pont az utolsót töröltük, akkor a segéd- 
táblánkból törölni kell a megfelelő sort. 
A trigger első részét kétféleképpen írhatjuk meg. Az első ver- 
zióban írunk egy kurzort a beszúrt sorokra, azaz az inserted vir- 
tuális táblára, és végigmenvén az összes módosított tételen 
mindegyiknél IF EXISTS(...)-tel lekérdezzük, hogy létezik-e már 
az összeg a másik táblában, és ha igen, akkor UPDATE-eljük azt 
az új értékre, ellenkező esetben INSERT-et hajtunk végre. 
Ez kezdő gondolat volt. Miért kell egyidőben elintézni a kétfé- 
le kezelést igénylő összegeket? Osszuk ketté a feladatot! Elő- 
ször írjuk meg azt az UPDATE-et, amely a már létező összege- 
ket módosítja, majd egy külön utasításban szúrjuk be azokat 
az összegeket, amelyek még nem szerepeltek a segédtáblában. 
Mondhatná valaki, hogy miért nem írok külön triggert az 
UPDATE-re és az INSERT-re, és akkor nem kellene kínlódni 
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a szétválogatással? Azért, mert nem az a lényeg, hogy be- 
szúrás vagy módosítás történt az alaptáblán, hanem az, 
hogy az behozott-e új OrderID-t a képbe? Mert mind az IN- 
SERT, mind az UPDATE képes erre. 

Nézzük hát a trigger első részét, ami azokat a részösszege- 
ket számítja ki és módosítja a segédtáblában, amelyek már 
léteznek: 


CREATE TRIGGER updinsSzummaSzamolo 
ON [Order Details] 

FOR INSERT, UPDATE 

AS 


UPDATE GyorsSzumma 
SET 
Szumma 5 
( 
SELECT 
SUM(Ouantity ! UnitPrice t (1-Discount)) 
FROM 
(order Details] 
WHERE 
OrderID - gy.OrderID 
GROUP BY OrderID 
) 
FROM 
GyorsSzumma gy 
INNER JOIN 
inserted 
ON --csak a módosított sorokra fusson 


gy.OrderID 5 inserted.OrderID 


A zárójelben található lekérdezés számítja ki a megfelelő 
összegeket. Típusát illetően ő egy ún. Correlated Subgue- 
ry, mert mint látható nem csak a levegőben számol, hanem 
a WHERE feltételében össze van kötve az UPDATE OrderID- 
jával, így mindig az éppen UPDATE-elendő sorhoz számol- 
ja ki a részösszeget. Az inserted táblával - amiben a fris- 
sen beszúrt vagy módosított sorokat adja át nekünk az SOL 
Server - azért kell összeJOlNolnunk az UPDATE-et, hogy 
tényleg csak a módosított sorokra számoljuk ki az összege- 
ket. Látható, hogy nem szűrjük ki azokat a sorokat, ame- 
lyekhez még nincs is bejegyzés a segédtáblában. Ezt meg- 
teszi helyettünk az UPDATE maga, mert ha olyan OrderID-ú 
sort akarunk módosítani, ami nincs is a céltáblában, egy- 
szerűen nem csinál semmit. 

Folytassuk a triggert, és nézzünk most azokat a sorokat, 
amelyekhez nincs még szumma a segédtáblában! 


INSERT GyorsSzumma 
(orderID, Szumma) 
SELECT 
od.OrderID, 
SUM(od.Ouantity t od.UnitPrice t 
(1-od.Discount) ) 
FROM 
[Order Details] od 
INNER JOIN 
inserted 
ON 
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od.OrderID - inserted.OrderID 
LEFT OUTER JOIN 

GyorsSzumma gy 
ON 

gy.OrderID - inserted.OrderID 
WHERE 

gy.-OrderId IS NULL 
GROUP BY 

od.OrderID 


Az INSERT bemeneti adatait egy SELECT-tel generáljuk. A 
SELECT-ben a LEFT JOIN-nal és a gy.OrderId IS NULL felté- 
tellel szűrjük ki azokat a sorokat, amelyek még nem létez- 
nek a céltáblában. 

Nézzük a törlés kérdését! Ezt egy külön triggerbe helyezzük, 
ami csak a DELETE-re lesz kiélezve. Azokat az összegeket 
kell törölni a segédtáblából, amelyeknek az ID-je nem talál- 
ható meg az eredeti táblában, de benne van a deleted táb- 
lában, azaz most törölték az utolsó tételt egy bizonyos 
OrderID-vel. Ne feledjük, hogy a DELETE trigger futásakor a 
forrástáblában már nincsenek benne a törölt sorok, mert a 
normál triggerek az őket kiváltó műveletek után futnak le 
(ezért is hívják AFTER triggernek) . 


CREATE TRIGGER delSzummaSzamolo 
ON [Order Details] 

FOR DELETE 

AS 


DELETE 
GyorsSzumma 
FROM 
GyorsSzumma gy 
INNER JOIN 
deleted 
ON --csak a törölt sorokra fusson 
gy.-OrderID - deleted.OrderID 
LEFT OUTER JOIN 
(order Details] od 
ON 
deleted.OrderID - od.OrderID 
WHERE 
--nem maradt ilyen tétel az 
--alaptáblában 
od.OrderId IS NULL 


Ezzel még csak a segédtáblából törlendő tételeket határoz- 
tuk meg és töröltük ki. Most még azokkal az OrderID-jű 
összegekkel kell foglalkoznunk, amelyekhez még maradt a 
forrástáblában azonos OrderID-jú tétel. Ezekhez újra ki kell 
számítani az összeget, és azt módosítani a segédtáblában. 
A script teljesen ugyanaz, mint amit az előző UPDATE- 
INSERT triggerben láttunk, csak most az inserted helyett a 
deleted táblában találjuk meg a számunkra érdekes sorokat: 
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UPDATE GyorsSzumma 
SET 
Szumma — 
( 
. mint a korábbi UPDATE-INSERT triggerben 
) 
FROM 
GyorsSzumma gy 
INNER JOIN 
deleted 
ON --csak a törölt sorokra fusson 


gy.-OrderID - deleted.OrderID 


És kész. A triggerünk csak a létrehozás után képes a segéd- 
tábla adatokat karbantartani, ezért a trigger létrehozása 
előtt vagy legyen üres a forrástábla, vagy kézzel töltsük fel 
a segédtáblát. Az utóbbira egy megoldás: 


INSERT GyorsSzumma 
(OrderID, Szumma) 
SELECT 
OrderID, 
SUM(Ouantity t UnitPrice t (1-Discount)) 
FROM 
(order Details] 
GROUP BY 
OrderID 


Lássuk munkánk gyümölcsét! Hogyan lehet nagyon gyorsan 
lekérdezni az összegeket? 


SELECT OrderID, Szumma FROM GyorsSzumma 


Ha az alaptáblából más adatokra is szükség van (ez a gya- 
kori) , akkor egyszerűen össze kell JOIN-olnunk az eredeti és 
a segédtáblánkat az OrderID mentén. 

Sajnos a szokásos , amit nyerünk a réven, elvesztjük a vá- 
mon" tétel most is működik, hisz az alaptábla módosításait 
jelentősen lelassíthatjuk az aggregálással. El kell döntenünk 
mikor vállaljuk fel ezt az időt. Egyszer úgyis rá kell szán- 
nunk, a kérdés csak az, hogy mikor nem (annyira) zavaró. 


Zárszó 

Az előző két oldalon egy igen primitív problémára, redun- 
dáns szummák karbantartására írtunk elég bonyolult trig- 
gert. Tényleg nekünk kell kielemezni a lehetséges végrehaj- 
tási ágakat, és tucatnyi hasonló kaptafájú triggert írni? 
Nos, SOL 2000-től már nem. Az előbbihez hasonló problé- 
mák megoldása eleve bele van építve a termékbe. A neve: 
meglepi. A jövő hónapban kiderül :) Visszavárom Önöket! 


Soczó Zsolt 
Zsolt.Soczo onetacademia.net 


A cikkben szereplő URL-ek: 


[1]: INF: Troubleshooting Stored Procedure Recompilation 0243586 

[2]: A cikkben szereplő script-ek http://technet.netacademia.net/download/sgl 

[31]: MS SOL Server 7.0 Performance Tuning Guide Chapter 20 - Transact-SOL Optimization and Tuning 
Inside Microsoft SOL Server 7.0 14. fejezet: Optimizing Ouery Performance 
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Bevezetés 

Sok időbe telik, mire a fejlesztők megegyeznek valamiben. 
Minden csoport hű az általa használt technológiákhoz, és 
nagyon nehezen vehető rá, hogy áttekintse a konkurens 
gyártók, technológia-diktátorok módszereit. S mi issza meg 
ennek a levét: a rendszerek együttműködési képessége. Lét- 
rejönnek alkalmazásszigetek a nagyvilágban, amelyek , há- 
zon belül" nagyon nyitottak, de a más típusú, önmagukban 
szintén nyitott rendszerekkel képtelenek kommunikálni. 
Lesz itt valaha megegyezés? Talán, igen. A kulcsszó: SOAP, 
Simple Object Access Protokol. 


Az elosztott alkalmazások kora 

Néhány éve még az volt a menő programozó, aki MFC-ben vagy 
Delphi-ben díszes, dokkolható és lebegtethető toolbar-okat és 
egyéb csicsás, lyukas és matyómintás ablakokat tudott létre- 
hozni. Azonban a világ változik. Amióta a számítógépeket 
összekötötték hálózati kábelekkel, azóta megvan a fejlesztők- 
ben és a megrendelőkben az igény, hogy olyan alkalmazásokat 
írjanak, amelyek több lóerővel működnek, azaz több számító- 
gép együttműködésével végzik el a feladatukat. Így a rendsze- 
rek nemcsak teljesítmény, de sokszor megbízhatósági előnyök- 
höz is jutnak, és mindezt sokszor olcsóbban, mint egy nagy 
böhöm vason megvalósított monolitikus társaik. 

Az elosztott alkalmazások igénye olyan technológiák kifej- 
lesztését követelte meg a nagy gyártóktól, amelyek elfedik 
a hálózati réteg bitfolyam jellegét, és a programozó számá- 
ra teljesen átlátszó módon képesek más gépen elhelyezke- 
dő programrészek, függvények meghívását biztosítani. Sőt, 
mivel a 90-es évek elején a hagyományos, moduláris progra- 
mozási paradigmát elhományosította az Objektum Orientált 
szoftverfejlesztés tana, a feljesztők olyan háttérinfratruktú- 
rára vágytak, amely objektumok vagy komponensek távoli 
létrehozását és kezelését biztosítja, számukra a lehető legegy- 
szerűbb és legtranszparensebb módon. 

Az igény megvolt, és a világ elindult a cél felé. Ahogy azt már 
megszokhattuk, a Microsoft elindult az egyik csapáson, és a 
UNIX-os világ is vágta a maga ösvényét, látszólag más irány- 
ba, a valóságban egymással párhuzamosan. A 80-as években 
két jelentősen elterjedt módszer volt a távoli eljáráshívásokra. 
Az egyik a Sun RPC (Remote Procedure Call, Távoli Eljáráshívás) , 
amelynek egyik legismertebb alkalmazása a UNIX rendszerek- 
ben elterjedt Network File System vagy ismertebb nevén NFS. 
A másik oldalon a Microsoft a DCE RPC-t használja még ma is 
a Windows-os, elsősorban NT alapú rendszerekben. 

Mindkét távoli eljáráshívási technológia működő, életképes, 
az évek során bizonyított, azonban nem objektumorientált. 
Mivel az 00P elvek keresztülverekedték magukat az egyete- 
mek vastag falain kívülre és a programozók fején belülre is, 
jogos volt az igény, hogy kellene valamilyen felsőbb réteg a 
RPC protokollok tetejére, amelyeken keresztül már objektumo- 
kat is rángathatunk a drót végén, nem csak globális függvé- 
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nyeket hívogathatunk. Megszülettek az ORPC protokollok, 
amelyek megpróbálták összebékíteni az objektumorientáltsá- 
got a hálózati protokollokkal. Ezt egyfajta cookie alkalmazá- 
sával oldották meg, azaz minden egyes kérésben elküldtek 
egy objektumazonosítót is a kiszolgáló folyamatnak, amely a 
saját adminisztrációs információiból tudta, hogy az ügyfél- 
program melyik objektumot akarja megszólítani. 

Egy tipikus ORPC kérés és válasz így néz ki: 


Kérés 


Objektum Végpont Azonosító 
(Melyik objektumot szólítjuk meg?) 
Interfészazonosító 
(Melyik interfészen van a keresett objektum?) 
Metódusazonosító 
(Melyik metódust kell meghívni?) 
Kiegészítő fejlécek 
(Mit felejtettünk ki a protokollból?) 
Paraméterblokk 
(Bemeneti és bemeneti-kimeneti paraméterek) 














Státuszkód 
(Sikeres volt a hívás?) 





Kiegészítő fejlécek 
(Mit felejtettünk ki a protokollból?) 


Paraméterblokk 
(Bemeneti és bemeneti-kimeneti paraméterek) 





Az Objektum Végpont Azonosító az előbb emlegetett cookie, 
amin keresztül a kiszolgáló tudja, melyik objektummal szeret- 
nénk foglalkozni. Az Interfészazonosító és a Metódusazonosító 
írja le a meghívni kívánt függvényt. A Kiegészítő fejlécek szol- 
gálnak olyan bővítések későbbi becsempészésére, amelyek még 
nem ismertek a protokoll kifejlesztésekor. A Paraméterblokkok 
célja nyilvánvalóan a metódusok paramétereinek szállítása. 
Manapság két jelentős ORPC implementáció virágzik: a Micro- 
soft részéről a DCOM (Distributed Component Object Model) , a 
UNIX-os világban pedig az Internet Inter-ORB Protokol, rövi- 
den IIOP, mely a CORBA protokollja. Mindkettő nagyjából a 
fenti struktúrákat használja a végpont azonosítására, de ter- 
mészetesen a konkrét mezők neve és száma különbözik. 
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Mindkét protokollban ki kellett dolgozni a paraméterek átalaki- 
tását byte-folyammá, majd vissza az eredeti jelentésükké 
(Stringgé, Integerré, satöbbi) . Ezt az oda-vissza alakítást hívják 
Serialization-nek illetve Deserialization-nek. Érdemes a szava- 
kat megjegyezni, mert a .NET kapcsán sokszor fogunk még ró- 
luk hallani. A DCOM az ún. Network Data Representation (NDR) 
formátumot használja, a IIOP Common Data Representation-t. 
A két formátum hasonló, de azért annyira különböznek, hogy a 
kétféle rendszer nem tud szót érteni egymással. 


Miért nincs egységes protokoll? 

Miért van az, hogy a világ egyik pólusa DCOM-on, a másik 
CORBA-n keresztül kommunikál? Mindkét protokoll hozzá 
van láncolva az őt kidolgozó céghez. Létezik ugyan DCOM 
implementáció UNIX-okra, de alig -ha egyáltalán- használ- 
ják őket. Sajnos az a helyzet, hogy a DCOM annyira hozzá 
van gyógyítva a Windows NT háttérinfrastruktúrájához, 
hogy nehéz bármilyen más platformon teljes hatékonyságá- 
ban kihasználni. A CORBA már sokkal több rendszeren imp- 
lementált, ám a különböző megvalósítások között is vannak 
olyan apró részletkülönbségek, amely miatt csak alapszin- 
ten működik jól az együttműködés, és - hasonlóan a DCOM- 
hoz - pont a finomságoknál (tranzakciók, biztonság) lesz- 
nek gondok a heterogén rendszerek együttműködésében. 
Mindkét technológia jól működik zárt, jól adminisztrálható 
belső rendszerben, leginkább cégen belüli kiszolgálók közöt- 
ti kommunikációra. Azonban mindketten megbuknak, ha be- 
jönnek a képbe a tűzfalak és az Internet. Márpedig ha tet- 
szik, ha nem, bejöttek. A mai rendszereknél egyre fokozódó 
igény van az összetevők Interneten keresztüli elérhetőségé- 
re. Annak az esélye, hogy a DCOM-hoz szükséges számtalan 
RPC portot kinyissa egy ,tűzfalgazda", közelít a nullához. 
Melyik az a port, amely még a legtöbb cégnél nyitva van? 
Igen, a 80-as, amely a webböngészéshez szükséges. Akkor 
miért nem lehet egy olyan réteget fejleszteni a DCOM illetve 
a CORBA fölé, amely a VPN-hez hasonló módon egy csatorná- 
ra tereli a teljes protokoll adatforgalmát? Például a HTTP pro- 
tokollra, amit olyan szívesen átengednek a tűzfalak. 

Ezek a technológiák léteznek, például Windows 2000-ben a 
DCOM-hoz COM Internet Services Proxy néven létezik egy kie- 
gészítés, ami rá tudja ültetni az DCOM-ot HTTP protokollra. 
Azonban ettől még nem fog kommunikálni a világ két ORPC 
rendszere, nem beszélve a konfigurációs bonyodalmakról... 


A HTTP, mint egy jobb RPC 

Miért pont HTTP? A HTTP-t hasonlóan az RPC-hez nagyon s0- 
kan használják, egyszerű, és ellentétben az RPC-vel a legtöbb 
tűzfal szívesen átengedi magán. A HTTP kéréseket általában 
webkiszolgálók fogadják, és legtöbbször rajtuk keresztül induló 
kiegészítő alkalmazások dolgozzák fel (pl. CGI alkalmazások). 
A DCOM-hoz és az IIOP-hez hasonlóan a HTTP is kérés-vá- 
lasz típusú protokoll. Az ügyfélprogram egy megadott TCP 
porton hozzákapcsolódik a HTTP szerverhez, amely általá- 
ban a 80-as porton figyel. Miután a TCP csatorna felépült, 
az ügyfélprogram elküldi a kérését, azt a kiszolgáló értel- 
mezi, feldolgozza, és visszaküld egy választ. A teljes kom- 
munikáció nyelvezetét a HTTP protokoll írja le. 

A következő kódrészlet egy egyszerű HTTP kérés: 
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POST /szappan HTTP/1.1 
Host: 172.16.0.200 
Content-Type: text/plain 
Content-Length: 11 


NetAcademia 


Látható, hogy a kérés szöveges formátumú, ami hibakeresésnél 
igen nagy segítség, hisz például Network Monitorral könnyedén 
visszafejthető a HTTP kommunikáció (ugye, ugye? — a szerk). 
Az első sor három elemet is tartalmaz: a HTTP metódust 
(POST), a kért URI-t (/szappan), és a protokoll verzióját 
(HTTP/1.1). A metódus a HTTP (és WebDAV) szabványban 
rögzített értékeket vehet fel, a példában szereplő POST-ot ál- 
talában akkor használjuk, ha a webkiszolgáló felé valamilyen 
információt szeretnénk eljuttatni. Ez a hagyományos webfej- 
lesztésben például egy kitöltött form adatait jeletheti. 

Az URI azonosítja a célobjektumot. Közönséges webszerve- 
IIOP hasonlattal élve az elérni kívánt objektum azonosítója. 
A harmadik és a negyedik sor a kiszolgálónak küldött tarta- 
lom típusát és hosszát azonosítja. A típus segítségével tudja 
az ügyfélalkalmazás a kiszolgáló tudtára adni az általa hasz- 
nált tartalomleíró nyelvezetet. DCOM-nál ez az NDR. HTTP-nél 
általában text/plain, ami közönséges ASCII szöveget jelent, 
vagy text/html, ami a HTML kódolt tartalmat jelenti. 

Mivel a HTTP fejléc hossza kérésenként más és más lehet, 
az utolsó fejléc után két kocsivissza-soremelés karakter is 
van, innen tudja a feldolgozó alkalmazás, hogy hol végző- 
dik a fejléc-blokk, és hol kezdődnek a valódi adatok, mely- 
nek hosszát és kódolását a Content-Length és Content-Type 
fejlécek azonosítják. Példánkban a tartalom (payload) 
hossza 11 byte, és tartalma NetAcademia. 

Miután a webkiszolgáló feldolgozta a kérést, visszaküld egy 
választ az ügyfélalkalmazásnak. A válasznak kötelezően tar- 
talmazni kell egy sikerességet jelző kódot, és ha akar, ak- 
kor a kéréshez hasonlóan további tartalmat is szállíthat. 


200 ok 
Content-Type: text/plain 
Content-Length: 12 


aimedacAteN 


A 200-as státuszkód a szabványos sikerességet jelző kód a 
HTTP protokollban. Az érdeklődők a teljes HTTP 1.1 szab- 
ványt a 2616-os RFC-ben találhatják meg a [1] címen. 


Az XML, mint egy jobb NDR 

Láttuk, hogy a HTTP protokoll nagyban kiválthatja az RPC-t, 
azonban van egy funkció, ami hiányzik belőle: a távoli me- 
tódushívások paramétereinek szabványos leírása. És itt jön 
a képbe az XML. 

Hasonlóan az NDR-hez és a CDR-hez, az XML is egy adatle- 
író protokoll, amely ráadásul szabványos és platformfügget- 
len is. Segítségével könnyedén átalakíthatjuk a paraméte- 
reket ASCII adatfolyammá (Serialization) , amelyet könnye- 
dén lehet hálózaton átvinni, és a céloldalon dekódolni 
(Deserialization). Igen előnyös tulajdonsága, hogy szinte 
az összes platformon bőséges a támogatottsága, szöveges 
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alapú, így egyszerű eszközökkel is könnyű feldolgozni, és 
nagyon könnyű egy már meglévő XML alapú formátumot 
egyértelmű módon kibővíteni. (Remélem cikksorozatunk 
rendszeres olvasóinak már kigyúlt az agyában a NameSpace 
fogalom lámpása, mint a bővíthetőség záloga.) 

A paraméterek struktúrájának leírására is már van kész esz- 
közünk (2001. április óta), amely nem más, mint az XML 
Schema. Az alábbi részlet egy olyan XML dokumentumot ír 
le, amelyben az elemek az urn:schemas-netacademia- 
net:SztringKolbaszolas névtérben laknak, a gyökérelem ne- 
ve HatraArc, aminek kötelezően van egy gyermekeleme mit 
néven, annak tartalma string típusú, és mögötte lehet még 
akárhány darab és típusú további elem. 


cschema 
xmlnsz "http: //www.w3.org/2001/XMLSchema " 
targetNamespace- ! urn : schemas-netacademia- 
4 net:SztringKolbaszolas "2 
£complexType namez"HatraArc"5 
Sseguence? 
Selement namez"mit" types"string" /2 
any minOccursz!0" 
maxOccursz! unbounded !" 
processContentsz"skip" /5 
£/seguence 5 
£/complexType? 
£/schemaz 


Azaz látható, hogy a mai állás szerint van egy adatrepre- 
zentációs szabványunk (XML [2]), és típus (struktúra) leí- 
ró szabványunk (XSD [3]). Mi akadálya ezekkel kiváltani az 
NDR-t és társait? Semmi! Helló SOAP! 


HTTP 4- XML - SOAP 

A SOAP szabvány nem tesz mást, mint összefogja az XML-t, 
mint a paraméterek kódolási szabványát és a HTTP-t, mint 
adatátviteli mechanizmust. Egy SOAP metódushívás nem 
más, mint egy egyszerű HTTP kérés és arra adott válasz, 
amelyben a kérés és válasz fejlécei, és azok tartalma meg- 
felel a SOAP szabványban előírtaknak. Ennyi az egész. A 
SOAP szabvány nem szól semmit arról, hogy a webszerve- 
ren mit történjék egy SOAP formátumú HTTP kérés hatásá- 
ra. Nem írja elő, hogy ettől egy COM objektumra képződ- 
jön le a kérés, egy sima DLL-nek hívjanak meg egy függvé- 
nyét, egy PERL modul álljon a kiszolgálás legvégén, vagy 
éppen egy WebSzerviz legyen a kiszolgáló. Bizony-bizony, 
a WebSzervizek hátterét kőkeményen a SOAP adja. Mi más? 
A SOAP kérés tulajdonképpen egy HTTP POST kérés. A Con- 
tent-type kötelezően text/xml. A Reguest-URI természete- 
sen kötelező, hisz ez azonosítja, hogy milyen objektumot 
vagy szolgáltatást akarunk meghívni a kiszolgálón. A HTTP 
kérésben kötelezően benne kell lenni egy fejlécnek, ami a 
meghívandó metódus nevét tartalmazza. E fejléc neve 
SOAPMethodName, és a tartalma a meghívni kívánt metó- 
dus neve egy URI-val megelőlegezve: 


SOAPMethodName: urn:schemas-netacademia- 


$  net:SztringKolbaszolasítHatraArc 
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Azaz szeretnénk meghívni a HatraArc metódust a urn: 
schemas-netacademia-net:SztringKolbaszolas névtérben. A 
névtér szerepe pont ugyanaz, mint DCOM-ban az interfész- 
azonosító. Felfoghatjuk úgy is, hogy a kettő együtt azono- 
sít egyértelműen egy metódust. 

A SOAPMethodName fejléccel tudatjuk a kiszolgálóval, 
hogy melyik metódust kívánjuk meghívni. A paraméterek a 
HTTP kérés törzsében utaznak, és a kódolásukra speciális 
SOAP szabályok vonatkoznak. Mik ezek? A paramétereket 
egy Envelope elembe, és azon belül egy Body elembe kell 
foglalni. A Body-n belül kell lenni a metódus nevét tartal- 
mazó gyermekelemnek, melynek a SOAPMethodName fej- 
lécben a metódus nevét megelőző névtérben kell lenni. 


POST /szappan/Amo HTTP/1.1 

Host: 172.16.0.200 

Content-Type: text/xml 

Content-Length: 163 

SOAPMethodName: urn:schemas-netacademia-net: 


4  SztringKolbaszolast$HatraArc 


ScEnvelope? 
cBody? 
cna:HatraArc 
xmlns:na- "urn: schemas-netacademia-net : 
4 SztringKolbaszolas"5 
cmitsNetAcademiac/mit: 
£/na:HatraArc2 
€/Body2 


€/Envelope? 


A SOAPMethodName-ben található metódusnévnek egzaktul 
egyezni kell a Body gyermekelemével (a névteret is beleért- 
ve), ellenkező esetben a fogadóalkalmazásnak meg kell ta- 
gadni a kérés kiszolgálását. Ez egy zseniális húzás, melynek 
segítségével a tűzfaladminisztrátorok anélkül tudják szabá- 
lyozni, hogy mely metódusokat hívhatnak meg a tűzfalon ke- 
resztül, hogy a tűzfalnak bele kellene nézni a kérés tartalmá- 
ba! Így nem kell kiegészíteni a tűzfalak alkalmazásszintű 
protokollszűrőit, mert a HTTP fejlécek szűrése minden komo- 
lyabb tűzfalba be van építve, és paraméterezhető. Emellett 
egy fejléc sokkal rövidebb lehet, mint a tényleges tartalom 
(gondoljuk például egy többezer elemű tömbparaméterre) , így 
a szűrés során nem kell nagy XML adattömegeket elemezget- 
ni, ami igencsak lefoglalná a tűzfalak processzorát. 

A SOAP válasz nagyon hasonló szerkezetű a kéréshez. A kime- 
neti vagy kétirányú paraméterek most is az Envelope/Body 
elemek vendégei, és az őket befoglaló elem neve a hívott me- 
tódus nevéből képződik egy "Response" utótaggal kiegészítve. 


200 OK 
Content-Type: text/xml 
Content-Length: 181 


cEnvelopez 
cBody2 
£Xna:HatraArcResponse xmlns:na-"urn: 
4  schemas-netacademia-net:SztringKolbaszolas "5 
ZresultsaimedacAteNc/result: 


£/na:HatraArcResponse? 
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DEVELOPER XMLGESSÜNK (V. RÉSZ) - 
€/Body? 


£/Envelope? 


Láthatjuk a szabványos HTTP státuszkódot (sikeres kiszolgá- 
lás - 200), és a borítékba zárt választ, amely ugyanabban a 
névtérben van, mint a kérés. A SOAPMethodName fejlécre 
most nincs szükség, ezért nincs is jelen. 

Ami elsőre furcsa, hogy a szabvány egy szót sem szól arról, 
hogy mi történjen a szerveren a kérés hatására. Az IIS pél- 
dául képes közvetlenül SOAP kérésekre válaszolni? Termé- 
szetesen nem, mint ahogy más webszerverek sem. De mind- 
egyiket könnyű kiegészíteni olyan módon, hogy alkalmas 
legyen erre. Windows 200x platformon a hamarosan végle- 
ges állapotúvá érő .NET Framework az, ami Microsoftos kör- 
nyezetben a legkényelmesebb hátteret biztosítja SOAP ki- 
szolgálók írására. Az, hogy történetesen a Microsoft föléhú- 
zott egy absztrakciós réteget, amit WebSzerviznek hívnak, 
senkit ne zavarjon meg. Amikor WebSzervizeket írunk .asmx 
kiterjesztésű fájlokban, akkor tulajdonképpen egy SOAP ki- 
szolgálót implementálunk. A .asmx lapnak SOAP formátumú 
kéréseket küldve ő nagyszerűen fog válaszolni, és a lapban 
implementált osztályok metódusait játszi könnyedséggel 
elérhetjük. Szerencsére a Microsoft egy lépéssel tovább- 
ment, és nekünk még csak nem is kell törődni a , csúnya" 
SOAP fejlécek és tartalom írásával, illetve a válasz elemzé- 
sével. Egy wsdl.exe nevű kis eszköz legyárt nekünk egy (C4, 
VB, JScript) forrásnyelvű .NET assembly-t, ami egy olyan 
osztály leírását tartalmazza, amely pontosan azon metódu- 
sokat tartalmazza, amiket a SOAP szerverünk (WebSzerviz) 
számunkra felkínál. A generált osztály mögött egy 
SoapHttpClientProtocol nevű osztály áll, ami magábazárja a 
SOAP protokoll által előírt összes részletet. Ami külön jó, 
hogy mi még ezzel sem kell, hogy érintkezzünk, mi csak ka- 
punk egy osztályt, amelynek metódusait meghívva egy tá- 
voli osztály aktiválódik, annak meghívódik az azonos nevű 
metódusa, a paraméterek jönnek-mennek (és nem csak egy- 
szerű integerek és társaik, hanem akár komplett osztályok 
is!), és az egészből semmit nem látunk ügyféloldalon. Sőt, 
még kiszolgálóoldalon sem! De ez már egy másik történet, 
amelyről még sokat fognak hallani Kedves Olvasóink. Kösz 
SOAP, kösz .NET framework! 


Hogyan lássunk neki? 

Remélem sikerült felcsigáznom a SOAP iránti érdeklődésü- 
ket, és már alig várják, hogy kipróbálhassák valami kis pél- 
daprogramon a technológiát. Milyen lehetőségeink vannak 
a kezdésre ügyfél és kiszolgálóoldalon? 

Kezdjük az ügyféloldallal. A Microsoft Interactive Developer 
2000. januári számában Aaron Skonnard publikált egy cik- 
ket SOAP: The Simple Object Access Protocol címmel. A cikk 
megtalálható az MSDN library-ban is. Áron írt egy nagysze- 
rű SOAP teszt ügyfélalkalmazást Internet Explorer 5-re. A 
cikkhez mellékelt  önkicsomagoló állományban a 
default.htm-et megnyitva indul el a SOAP teszter alkalma- 
zás. A megadott SOAP szerver-végpont és metódusnév meg- 
adása után a Call Method gomb megnyomására induló függ- 
vény összeállítja a SOAP kérést, és az XMLHTTP objektum 
segítségével elküldi a kérést a SOAP kiszolgálónak. A kérést 
is és a kapott választ is megtekinthetjük a lap ablakaiban. 
Az alkamazás letölthető a [4] címről is. 
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ZÁES Generic SDAP 
] Ele Edt Wew  Favorttes Tools Hep 


[8-0 - A A Alosa ges 
]Adóress [E] v Document pam ISOAPISkonnardsOAPTesttIES-SOAP-Ckent Locafjdefauit.htm 7 Íge 


JUnks £)XSLHDOM ÉJXSLHADO £) XSL-HXSLCache £] ADOSavexML £) XML sablon 
Enter SOAP Reguest AJ 


Either choose one of the pre-configured test endpoints or manually enter 
the SOAP reguest data below. 


Test-Endpoints: [show descriptions] 

[eegtszpdgebpoom szpdem see s 
Endpoint: 

[htp/so0ap.develop com/soapdemojsession.asp 

Interface: 

soap:cdi:com. develop sospdemo VBSoapSrv. VBSoapTest 

Method: 

fTranstate 

Payload (XML): 

[eTranslatescp aj 


eypes"soap:cd1:com. develop. soapdemo . VBSoapSrv.point"5cx 
eypes"i4"5200€/x2€y typer"i4"5500£/yoc/popc/Translates 


icrosoft Internet Explort 






































T Use M-POST (othervwvise regular POST) 


Call Method Clear Input Fields. 





SOAP Results 


Original SOAP Reguest 


Reguest Headers 








[PosT nerp://s0ap.develop.com/ soapdemo/session.asp  HTTP/1.1  ] 5] 
(TR Done TT TT Mv Comouter 4 
Zárszó 


Nem beszéltem a másik oldalról, a SOAP kiszolgálókról. A 
témakör megér még (minimum) egy misét, így azzal a kö- 
vetkező részben fogok foglalkozni. Megnézzük a SOAP Tool- 
kit szolgáltatásait is, és írunk egy VB alapú és egy PERL ala- 
pú SOAP kiszolgálót IIS5 alá. Akinek van kedve, az akár egy 
Linux-os gépen is megírhatja a kiszolgálókomponenseket 
Apache, vagy egyéb http daemon alá is, köszönhetően a 
PERL hordozhatóságának. Hol van már a ,a Windowsos prog- 
ramok csak Windwosos progamokkal működnek együtt" vi 
lág! A múltban, igen nagy örömünkre. 


Írta és rendezte: Soczó Zsolt 
Zsolt.Soczo (onetacademia.net 


L-ek: 
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[11]: RFC2616 
http://www.w3.org/Protocols/rfc2616/rfc2616.html 
[2]: XML szabvány 
http://www.w3.org/TR/2000/REC-xml-20001006 
[3]: XML Schema 
http://www.w3.org/TR/xmlschema-O 
[4]: Letölthető kódok 
http://technet.netacademia.net/download/xml 
[5]: SOAP szabvány 
http://www.w3.org/TR/SOAP 
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MS Exchange 


- Miért indul 


lassan az Outlook? 


MS Exchange - Miért indul lassan az Outlook? 

K: Az egyik ügyfelünknél újratelepítettük a szerverüket 
(Windows 2000-ről SBS 2000-re). A munkaállomásokat átál- 
lítottuk az új kiszolgálóra, telepítettük az Outlook 2000-et 
a megosztott clientapps könyvtárból. A kliensek némelyi- 
kén iszonyatosan lassan indul el az Outlook, némelyik azt is 
mondja, hogy a kiszolgáló nem elérhető, de "újra próba" 
után megtalálja. Emlékeim szerint ennek megoldására jó a 
NetMon: valami névfeloldással kapcsolatos fejtegetés rém- 
lik, de több nem jutott eszembe... 

V: Az Outlook indulásakor (és minden további kommunikáció 
során RPC (remote procedure call)) kapcsolatot kezdemé- 
nyez, és használ az Exchange kiszolgálóval, mely a Registry 
RPC kötési sorrendjén alapul (RPC binding order) . Az Outlook 
úgy keresi meg a kiszolgálót, hogy ellenőrzi a rendelkezésre 
álló hálózati útvonalakat és névfeloldást végez. A bejegyzés 
meghatározza, hogy az Outlook milyen hálózati protokollo- 
kat, és milyen sorrendben használ a kereséshez. 

Az alapértelmezett beállítás: 


[HKEY LOCAL MACHINEVSOFTWAREMMicrosoftNExchange] 
Az Exchange Provider értéke: 
"ncalrpc,ncacn ip tcp,ncacn spx,ncacn np,netbios, 


b ncacn vns spp" 


Azaz elsőként helyi feloldást végez ((rpc-local mc), amely ha 
nem sikerül (és miért is sikerülne? Az Outlookok elenyésző hánya- 
da fut ugyanazon a gépen, mint az Exchange kiszolgáló!) , pró- 
bálja a következőt, s ez egészen addig megy, amíg meg nem ta- 
lálja a megfelelő módszert - vagy hibaüzenetet ad vissza, ha 
nem találta meg. Ha kellően hátul van a sorban a megfelelő pro- 
tokoll, ez a folyamat igen sokáig, akár fél percig is eltarthat. 

A megoldás így - mivel az Outlook NetBIOS néven keresi az 
Exchange kiszolgálót - a protokollsorrend megváltoztatása. 
A named pipes minden protokoll esetén sikeres gyors csat- 
lakozást biztosít, így ezt célszerű első helyre tenni: 


"ncacn np,ncalrpc,ncacn ip tcp,ncacn spx,netbios, 


b ncacn vas spp" 


A hosts fájl módosítása javíthat a helyzeten, hiszen a név- 
feloldást gyorsítja, de a korrekt megoldás a fenti Registry 
bejegyzés megváltoztatása. 

Forrás : NetAcademia Exchange 2000 lista 


Windows 2000 - az automatikus programindítás letiltása 
K: Hol lehet a Windows 2000 Server-ben letiltani a bekap- 
csoláskor elinduló programokat? Feltettem a Real Player 
8.0-t és le szeretném tiltani, hogy minden bejelentkezéskor 
elinduljon, és az óra mellé rakja ikonját. 

V: A Windowsban (sajnos, vagy hála Istennek) több automa- 
tikus programindítási lehetőség található. Ha meg szeretnénk 
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szüntetni az automatikus indítást, akkor az összes helyet, a 
rendszer indítópultját (Startup folder(ek) ) , és a Registry meg- 
határozott bejegyzéseit végig kell néznünk a törléshez. 

A registrybejegyzések a következők: 


RUN és RUNONCE kulcsok 

HKEY LOCAL MACHINElSoftwarelMicrosoftlWindowsY 
4 CurrentVersionlRun 

HKEY CURRENT USERlSoftwarelMicrosoftWWindowsN 
4 CurrentVersionlRun 

HKEY LOCAL MACHINElSoftwarelMicrosoftlWindowsY 
4 CurrentVersionlRunOnce 

HKEY CURRENT USERlSoftwarelMicrosoftWindowsN 


8 CurrentVersionlRunOnce 


A RUN és a RUNONCE kulcsok a HKLM és a HKCU listában is 
szerepelnek, azaz mind globális, mind felhasználónkénti 
bejegyzések rendelkezésre állnak. A HKLM-ben lévő bejegy- 
zések a felhasználó desktopjának létrehozása előtt, a 
HKCU-ban lévők a desktop létrehozása után indulnak. A 
RUN bejegyzés alatt a programok minden felhasználói belé- 
péskor elindulnak. Az adat értéke a futtatandó parancs. 
(Csökkentett üzemmódban ezek nem indulnak el.) A RUNONCE 
bejegyzés egyetlenegyszer végrehajtandó parancsokat tar- 
talmaz, ezek a parancs végrehajtása után törlődnek. Vannak 
olyan bejegyzések is, melyek bejelentkezés előtt is lehető- 
vé teszik alkalmazások futtatását, ezek a: 

RUNSERVICES és RUNSERVICESONCE kulcsok. 


HKEY LOCAL MACHINElSoftwarelMicrosoftWWindowsN 
$ CurrentVersionlRunServices 
HKEY CURRENT USERlSoftwarelMicrosoftWWindowsN 


8, CurrentVersionilRunServicesOnce 


A RUNSERVICES és a RUNSERVICEONCE kulcsok alatti prog- 
ramok minden rendszerindításkor elindulnak. Az adat érté- 
ke egy parancssor. A registrybejegyzések és az indítópult- 
ban szereplő programok végrehajtási sorrendje a következő: 


HKLMISoftwarelMicrosoftlWWindowsiCurrentVersionV 
4 RunServicesOnce 
HKLMISoftwarelMicrosoftWWindowsiCurrentVersion) 
4 RunServices 

[Bejelentkezés] 
HKLMISoftwarelMicrosoftlWindowsiCurrentVersion) 
3 Runonce ő 
HKLMISoftwarelMicrosoftlWindowsiCurrentVersiont 
9 Run 
HKCUlSoftwarelMicrosoftlWindowslCurrentVersion)t 
8 Run 

Indítópult 
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DUPLA KV 


HKCUNlSoftwarelMicrosoftWWindowsiCurrentVersionV 


HW  RunOnce 
Forrás : NetAcademia Windows 2000 Lista 


Windows 2000 - IP cím gyors megváltoztatása 

K: Hogyan lehet maximum két kattintással IP címet cserél- 
ni Windows 2000-ben? 

V: A feladat megoldható, de jelen esetben nem a Windows 
mélyén rejtőző titkos menüpontot kell keresni: a megoldást 
a Windows beállítási ablakain kívül találjuk. 

Kevesek által ismert és használt eszköz a parancssorból in- 
dítható netsh.exe. Ez a program nélkülöz minden dekorá- 
ciót (ablakot, checkbox-ot stb.), egyszerű és hatékony, a 
karakteres terminálablakokhoz szokott szíveket melengeti. 
Emellett igen nagy előnye a parancssorból való indítás le- 
hetősége és a parancssori paraméterezés. (a jelen feladat 
megoldásához ezt a tulajdonságát lehet kihasználni) . 
Néhány szó a netsh használatáról: 

A netsh a következő beállítások elvégzésében segít: 

8 interfészek 

routolási prorokollok 

szűrők 

routolás 

RRAS 

Beállítások kiíratása tetszőleges routeren 
Parancsvégrehajtás adott routeren 

Az egyes célfeladatokat a feladathoz csoportosított környezet- 
ben tudjuk elvégezni. (pl. interface, routing ... környezet). Ha 
interaktív módban használjuk, parancssorból a netsh parancs 
kiadásával indítható egyszerű promptot kapunk: (netsh2),a 
parancsokat ez után kell kiadni és ENTER-rel lezárni. 

A legfontosabb parancsok: 

0 ? - segítség kérése adott környezetben 

"A exit - kilépés a programból 

0 interface - belépés interface környezetbe 

8 .. - feljebb lépés alkörnyezetből 

"b dump - környezet beállításainak listázása 

"0 set - beállítás 

A fenti lista korántsem teljes, de elegendő a feladat megoldá- 
sához. A közelebbi ismerkedéshez a ? egyértelmű segítséget ad. 
Az előző parancsok a netsh paramétereiként megadva egy 
sorban lefuttathatók. Így az eredeti feladathoz a megoldás 
első lépése a végrehajtó parancssor elkészítése, mely a kö- 
vetkezőképpen néz ki: 


HFddddd 


netsh interface ip set address 10.1.1.111 


Az IP cím egy előre kiválasztott cím, de kis további bűvész- 
kedéssel ezt megadhatóvá tehetjük a parancsunk számára. 
Ezt a sort kell már csak kattintással elindíthatóvá tenni, 
amit legegyszerűbben egy parancsikonnal tehetünk meg. 
Forrás : Netacademia Windows 2000 lista 


Windows 2000 - TerminalServer jogosultságok 

K: Adott egy NT4-es domain és egy Win2k-s TerminalsServer. 
Hogyan tudom megtenni azt, hogy csak bizonyos domain 
usereknek engedélyezem a TS használatát? 

V: A kliensek RDP-TCP kapcsolaton keresztül jelentkeznek 
be a Terminal Serverbe. Egy szerveren egy hálózati kártyá- 
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ra egy RDP (Remote Desktop Protokol) kapcsolat konfigu- 
rálható. A Terminal Services Configuration menüben be le- 
het állítani az RDP kapcsolat következő paramétereit: 

"2 atkliens maximális kapcsolódási ideje 

0 titkosítási szint 

"A felhasználói jogok 

"8 csoportos jogok 


1 Logon Settngs Sessions 
Remote Control] Ctent Settings 


Network Adapter 





2 Admiréstratoss (FLAME VAdministrators) 
62 SYSTEM 
ET Users (FLAMEWsers) 


0 A Terminal Services jogai az RDP protokollon állíthatók be 


Ha permissions pont alatt csak egy bizonyos csoportnak 
(pl.:TERMSERVER-USERS) van bármilyen jogosultság beállítva, 
akkor csak a csoport tagjai tudnak belépni, a többiek nem. 
(Ezzel a beállítással egyébként felülbírálható, hogy Administ- 
ration üzemmódban kik férhetnek hozzá a Terminal Serverhez. 
Gyárilag csak a rendszergazdák, de ha ügyesek vagyunk...) 
Forrás : Netacademia Windows 2000 lista 


Windows 2000 - DNS áttelepítés 

K: Hogyan lehet egy Windows NT 4.0 DNS kiszolgáló bejegy- 

zéseit (esetleg beállításait) egy másik NT 4.0 DNS-re egy- 

szerűen átrakni (esetleg Windows 2000-re is)? 

V: A Windows NT 4.0 DNS szervere kétféleképpen működhet. 

1. BIND (Berkeley Internet Name Domain) kompatibilis mód- 
ban, ami rendkívül sok névszerverhez hasonló paramé- 
terfájlok használatát jelenti. 

2. Registry alapú módban a registryben tárolt bejegyzések ké- 
pezik a DNS paramétereket a 


HKEY LOCAL MACHINENSYSTEM(CurrentControlsSetN 


4 ServicesiDNSlParameters 


kulcs alatt. 

A BIND kompatibilis mód két típusú szövegfájlt használ, 

mindkettő a "osystem9otsystem32 dns könyvtárban található. 

"0 A BOOT fájl (BIND elnevezése általában named.boot) a 
szerver alapbeállításait tartalmazza. 

"8 Azónafájlok, melyek az egyes név-cím hozzárendeléseket 
tartalmazzák a különböző domainekre; elnevezésük a 
rendszergazda feladata. 

Registrymódban a fenti fájlok tartalmának megfelelő kul- 

csokban állíthatók be a DNS paraméterek. A legtöbb beállí- 

tás elvégezhető a DNSADMIN eszközzel, de néhány adat 
csak a Registryben szerkeszthető. 
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DUPLA KV 
A két mód közötti átjárhatóságot a 


HKEY LOCAL MACHINENSYSTEM(CurrentControlsSett 


4  ServicesXDNSlParameterslEnableRegistryBoot 


kulcs jelenti, mely hamis értéke a BIND kompatibilis mó- 

dot, igaz értéke a Registrymódot állítja be. Figyelem! BIND 

alapú módba kapcsoláskor a Registryben beállított értékek 
nem kerülnek át a szövegfájlokba! 

Az adatok átvitele két DNS kiszolgáló között a két üzem- 

módban különböző. Elsőként állítsuk le a DNS kiszolgálót 

(pl.:parancsmódban: net stop dns), majd: 

BIND kompatibilis módban: 

1. a "osystemroot9otsystem32ddns könyvtár teljes tartal- 
mát másoljuk át az új gép ugyanezen könyvtárába. 

2. állítsuk be a Registryben a fenti kulcsot a használatnak 
megfelelően. 

3. indítsuk el (újra) a DNS szolgáltatást 

Registrymódban: 

1. a "osystemrootyolsystem32 dns könyvtár teljes tartal- 
mát másoljuk át az új gép ugyanezen könyvtárába. 

2. másoljuk át a forrás gép Registryjében lévő 
HKLMNYSTEMN...NDNS (lásd fentebb) kulcs tartalmát 
az új gépre 

3. indítsuk el (újra) a DNS szolgáltatást 

Ja, és a Registry szerkesztése előtt végezzünk biztonsági 

mentést! 

Forrás : Netacademia Windows 2000 Lista 


Windows 2000 - Service Pack a telepítőben, slipstreaming 
K: A slipstreaming használatáról keresek valami leírást 
(how-to-t) A technet elég szűkszavú, csak az update kap- 
csolók között említi. 

V: A slipstreaming a Windows 2000 egyik legígéretesebb új- 
donsága, mely a Service Pack 1-ben volt először jelen. Le- 
hetővé teszi olyan (hálózaton megosztott) telepítőkészle- 
tek létrehozását, melyekben a Service Pack javításai jelen 
vannak. Ezáltal a rendszertelepítést követően nincs szükség 
a SP külön telepítésére, s a későbbi komponenstelepítések- 
nél sem kell , újrahúzni" a javítócsomagot. Így készül: 


NO MÉG EZ A 
CIGI ÉS MEGYEK. 
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1. Az eredeti Win2k telepítőkészletet (a könyvtárstruktúra 
megtartásával (bootdisk, clients, i386...)) másoljuk fel 
egy könyvtárba (pl. c: Iw2kdistr) 

2. Csomagoljuk ki a Service Pack-et egy másik könyvtárba, 
(pl. c: win2kspack, de ha kicsomagolva megvan pl. CD-n, 
az is jó) 

3. Indítsuk el az update.exe-t a következő formában: 
update.exe /s:c:"w2kdistr 

4. Ez végrehajtja a telepítő frissítését, amiről innentől kezd- 
ve utólagos Service Pack telepítés nélkül lehet Win2k-t 
feltenni. 

Tippek és tapasztalatok: 

1. Az új telepítőkészlet nemcsak merevlemezről és hálóza- 
ton tud működni. A bootolható CD sok helyen jobb 
megoldás lehet. Bootolható telepítő CD készítéséhez 
információt a következő weboldalakon találhatunk: [1] 

2. Ha az új (SP-kel kijavított) telepítőkészletről készítünk 
boot floppyt, akkor az i386 könyvtárból másoljuk rá 
az első telepítő floppyra az új (SP-vel kijavított) 
txtsetup.sif fájlt 

3. A recovery console-t nem frissíti inplace upgrade esetén, 
csak ha újrafuttatjuk a winnt32.exe-t /cmdcons kap- 
csolóval (a slipstream-mel javított telepítőről) . 

4. RIS szerver esetén szükséges egy kis plusz munka, mivel 
próbálkozáskor a következő hibaüzenetet kapjuk: , The 
server to which you chose to replicate does not contain 
a cd-based image. The version of the cd-based image 
on the server must match the version of the system 
you are attempting to copy. Select a different server or 
add a cd-based image to this server." 

Ez utóbbi problémát a következőképpen oldhatjuk meg: 

1. Másoljuk a teljes Win2000 telepítőkészletet egy megosz- 
tott könyvtárba 

2. A fent leírt lépéseknek megfelelően végezzük el a slip- 
stream frissítést (update.exe /s:c: Iw2kdistr) 

3. Mihelyst elkészült a javítás, a RIS szerveren el kell indí- 
tani a RISETUP.EXE programot, hogy új image-et adjunk a 
szerverhez. A javított könyvtárat kell megadni forrásként 

Forrás : Netacademia Windows 2000 Lista 


A cikkben szereplő URL-ek: 


V- 


DUPLA 





[1] http://www.windows2OOOfag.com/Articles/Index.cfm?ArticleID-13914 


http://vilagokorseg.hu 
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FUN 


Problémamegoldás felsőfokon! 





TESz E 1] 


A számítógépen az egyik mappa vagy fájl ("C:WProgram") bizonyos 
alkalmazások nem megfelelő működését eri ij, Ha átnevezi 
a következő névre, megoldhatja problémát: "C:WProgram1", Átnevezi 
most? 





I Ne ellenőrizze indításkor 


frnevezés [ TI 





Petrény Zsolt a kihagyás mellett döntött: rosszul tette! 


Az a sok-sok nemzet! 


Microsoft Management Console É XI 


AN Could not start the Cluster Service service on Local Computer, 





Error 5086: France 








Úgy tűnik, a Francia jogi szabályozás nemcsak bizonyos 
titkosítóalgoritmusok, hanem a Cluster Service használatát 
is korlátozza! 


Multiuser environment 
Microsoft Word 


( ? § Citevedrvevre. virtual, file. rvesrv.olk foglalt, Unknown használja. Kér másolatot? 


Nem 











Gyúri Attila ugyanazon a bonyolult fájlon próbált dolgoz- 
ni, mint Unknown. De ki az az Unknown? 


Az univerzum mégsem tágul? 





Scriptum GIB 


2] 


€9 Kísérlet történt a(z) ismeretlen file végén túli olvasásra. 


[EC 





Nagypál Gábor az emberi tudás határait feszegetve buk- 
kant a következő hibaüzenetre: a Windows súlyosan korlá- 
tozza szárnyaló fantáziáját! 
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Problémamegoldás 


felsőfokon! 


Tömény információ 


About Information Service 





Description: Microsoft Personal Folder/address ! 
Company: Microsoft Corporation 


Version: 5.5.3121.0 

Language: English (United States) 

Size: 1/22/2000 2:57:28 AM 
ESETE Ess nmE sza 





Zalavári Balázs bukott el ezen a párbeszédpanelen, ugya- 
nis képtelen volt felismerni a dátum formátumát: ritkán, 
de előfordul, hogy bájtban adják meg! 1 bájt - 0,2542e2 
másodperc. A méret kifejezésére pedig komolyabb helye- 
ken a DD/MM/YYY HH:MM:SS formátumot használják, mert 
az pontosabb mérést tesz lehetővé! 


Helyreigazítás és bocsánatkérés 


Sajnálattal értesültünk a napilapokból, hogy augusz- 
tusi szoftverrazzia tréfánk valóra vált, s az ott feltün- 
tetett négy helyiségből háromban valóban volt rendőr- 
ségi akció. Akkor még senkit sem kívántunk kellemet- 
len helyzetbe hozni ártatlan tréfánkkal, de most, telj- 
hatalmunknál fogva a következő városokba rendelünk 
szoftverrazziát októberre :-) 





Alsónémedi 






Százhalombatta e. 








e e 
Dunaharaszti 


e Nagykanizsa 
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-.NET testközelben! 


A NetAcademia júniustól elindította intenzív .NET 
felkészítő tanfolyamait, ahol elsőkézből megtanul- 
hatja a legújabb technológiákat. 
2124 - Introduction to Ctt Programming for the 
Microsoft .NET Platform 
5 napos intenzív kurzus, ahol részletekbe 


GEL BADZUI 


üM 


Access-VB-SOL Advisor 
A/C Elyer 

Architectural Record 
Aviation Week 

Business 8. Commercial Aviation 
Business Security Advisor 
Business Week 
Design.Build 

Dr. Dobbs Journal 
e-BUSINESS ADVISOR 
Electrical World 

ENR 

FileMaker Pro Advisor 
FoxPro Advisor 

Harvard Business Review 
Healthcare Informatics 
The Hollywood Reporter 


menően megismerjük a CH lelkivilágát. 
2063 - Introduction to ASP.NET 
3 napos , átképzés" ASP fejlesztőknek, 
ADO.NET-tel fűszerezve. 
1913 - Exchanging and Transforming Data 
Using XML and XSLT 
5 napban az XSLI-ről, alfától-omegáig. 


Bővebb információk: 


BYIE 
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Hospital Practice 
Infoconomist 

Information Week 

Internet Week 

Lotus Advisor 

MSDN Magazine 

Network Computing 
Network Magazine 

New England Journal of Medicine 
Overhaul 8: Maintenance 
Physician 8. Sportsmedicine 
Postgraduate Medicine 
Power 

tele.com 

Unicenter TNG Advisor 
Websphere Advisor 

World Aviation Directory 


Newsletters: 

Aviation Newsletters 

Energy 8 Business Newsletters 
New England Journal of Medicine N. 
Platts Newsletters 

UDI Newsletters 


Advisor Archival CD-s: 
Access-VB-SOL Advisor 
Lotus Advisor 

Business Security Advisor 
e-Business Advisor 
FoxPro Advisor 

FileMaker Pro Advisor 
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A tanfolyamkódoek megfejtéséért és 
" további információért látogasson el honlapunkra: 


http:/ / www.netacademia.net 
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és juttassa el hozzánk az alábbi megrendelőlapot. Előfizetőinket szeretettel várjuk Mesterkurzusainkon ahol - 
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